Aerospace Village - Cybersecurity meets Aviation Regulation
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Cornelius, Aaron
Brom, Tim
Software development for aviation is highly regulated, and process driven. The current processes, as defined in DO-178C and related standards, originate from a history of designing and testing mechanical components. In the past you designed a part and once installed it only had to be monitored for physical condition. It was assumed that maintenance procedures would be able to identify which components are in flight condition and which are not. But now that there are USB ports and iPads in the cockpit, do these previous assumptions remain valid? How can we ensure that flight systems are not compromised after being installed? What can be done to help ensure aviation systems are secure? There are 4 primary areas of concern on a modern aircraft: Maintenance interfaces - What is necessary to ensure that software communicating with the aircraft is correct and operates in a secure manner? Passenger interfaces - What is necessary to ensure that systems passengers interact with cannot interfere with the aircraft operation? Crew accessible interfaces - What is necessary to ensure that the crew cannot accidentally connect a malicious device to flight systems? Pre-flight software validation - Is there a procedure that could be used to ensure that the software running on aircraft systems is 100% correct and unmodified?
 I'm Aaron Grealius. I'm a security researcher with Grim. I'm a cyber physical systems team. We work on improving the security of embedded devices everywhere. I've also got a background along background and embedded software development on critical systems. The telecom, aerospace, medical and a bunch of different fields. My name is Tim Brum. I run the cyber physical systems team here at Grim. I've been at Grim for about five years now, hacking all sorts of different types of embedded systems from aerospace to automotive, heavy trucking, medical. Now we're here today to talk about some of where cybersecurity meets aviation regulations. I'm going to start by talking about the current status of cybersecurity regulation and more how software development happens in aerospace. The current process that we have descends from the historically how airlines have approached the topic of safety. Airlines have approached the topic of safety usually historically from a purely mechanical standpoint. This part will last for about this long in airplanes. So that's very placed every so often. There's maintenance procedures and everything this direct is to talk about how often these parts need to be replaced based on how on it takes them to fail. There's things that they test. Like anywhere you have stresses on a metal joint, you'll have testing done both visual inspection and other types of testing depending on circumstances to see if it's starting to fail, starting to get cracks forming in those areas. But it's really designed around this concept that once you make a part, it behaves in some sort of defined way that doesn't change. Once you design it, do all your fairly rigorous testing that they do in the airline aerospace industry and install it. Like it will change in ways they're defined essentially by the physics of the situation. Stresses on metal, opening and closings of latches and stuff like that. That have a defined physical characteristic and you can define maintenance procedures that will detect all of these potential issues on the airplane. The maintenance procedures you're defined to replace things that you need to replace periodically. These maintenance procedures are, you can follow it between the commercial aerospace world will be followed. You may rely on that happening that does happen. And they do it in places like this. They have drawers that have labeled places for every bit, every socket, every tool. It's access controlled. So you know that when you do your maintenance procedure, there's a procedure for using this size socket to remove these bolts and you put it back when you're done. So you don't wind up leaving a socket in an airplane. They have these fairly strictly defined procedures that you follow in order to make sure that all of these maintenance is done correctly and done completely. So that's the kind of history of where we came from. As far as the current regulations that drive the software development process for our modern aviation software, that's regulated at least in this country and many other ones, by something called DO-170AC. We're not going to go into this too deeply, but knowing how things work right now and how levels of safety are defined will help us think about cybersecurity and where, how to go forward with that. This is developed by RTCA. It stands for Radio Technical Commissions for Aeronautics, which I never actually know until I look that up. It's not super important, it's just an organization that develops a bunch of aviation standards. And again, these are adopted by FAA in the United States, Transport Canada, and the European Aviation Safety Agency, EASA. So what is DO-170AC? I like to summarize it this way. You basically tell the FAA, well, a DER, it's the designated representative that stands in for the FAAs, tell them how you plan on designing, creating, and testing your software. And then you go and follow your plan and do those things, and then you have to prove that you followed your plan. That's it in a nutshell. Now, there's a lot more paperwork involved. There's a lot of checklists you do have to go through and make sure that your plan actually does identify all of the areas of concern that DO-170AC points out. And if the DER thinks that anything is lacking in your plan, they will tell you and help you make sure that it gets revised appropriately. That's the way things go forward right now. And as you can see, it's kind of a very water-folly-based model where you do all of your design upfront. You create a design, you create a spec, that actual product that implements the design, that you do testing on it in order to make sure that your the product you designed actually meets the requirements that the product was supposed to fulfill. That is a good point. The way this does work in practice, it is extremely waterfall. If there's been attempts to try and figure out how to fit agile methods into this, but it is very much planned to prove just pretty much in those steps. And this again comes from that historical background of making mostly mechanical components where that is how you design them. You don't do iterative development on a weight usually. I mean, if there's issues, you'll go back and fix them, of course. There is no fail fast on making a lot of these mechanical components. So it's trying to shoehorn software development into how they make mechanical components for these aircraft. And has anybody who's been in software development for a while knows that waterfall has been around for a long time. The U178C categorizes different levels of software according to the potential consequences of a failure of that software. So levels A through E. And basically A means that something catastrophic would happen if it fails. Level E means that nothing is going to happen safety-wise. Maybe your passengers can't watch movies. That would be a level E software. The level A is also the highest cost. It's probably unsurprising. The last numbers I can find show that it's estimated to be about $100 per line of code for level A software. There's not all software on an airplane is level A. There's usually just a small percentage as possible because of the cost. But Boeing 787, for example, is estimated to happen between six and seven million lines of code. So even if it's a small percentage, just the level of certification alone of the software drives a great deal of cost. Basically, these go from different levels. So level A catastrophic software usually software that is level A rated will have autonomous control. Which means that there's no way to intervene if something fails. Hence why it's so expensive and so time consuming to develop. Then they go on both. Level B would be something where something hazardous could happen. But also level B will typically allow for pilot intervention. So it might be something that significantly increases the workload or the challenge of flying the aircraft. But it would be something that can be addressed by the pilot's pilot training. Level A and B is usually lost in life. Like a level A failure was likely to lead to loss of life. Level B failure is not likely to lead to loss of life or severe injury. Injury sustained at a level B failure should be minimal. And then it goes on down from there. C and D are major, minor impacts to the flight of the aircraft. Also, so entertainment systems are going to be level E. Means that there's lower, less regulations and less checklist essentially. As you go down in level, you have to do less to prove in that proof set. So in the 178c, code is expensive. So stuff, especially at the level B or level A is very unlikely to have unused code in it or unnecessary code in it, like a shell onto a system. It's, you know, actually, in 178c, you're not allowed to have dead code in your design on the system. So there's a little, because it's so expensive to develop the code, there's usually a minimal amount of code on these systems. There is extensive testing done for the higher certification levels. It's at least a significant quantity of testing done. Pilot training, how to use the software is, and the other systems are designed for redundancy and safety. So if you do have a failure, you can use the system to do that. But if you do have a failure, there should be a redundant system to back up that failure, unless you have a 737 max, but we won't talk about that right now. Very limited interfaces on these flight critical systems. They use the differences like R&429. R&429 is a UR style bus. You're limited to sending the 32 bits of data at a time. So there's not really room for buffer overflow here, you don't really have longer messages on top of R&429. These interfaces are very strictly defined and fairly limited, provide very limited functionality beyond just sending the necessary critical data back and forth on the bus. Yeah, there's a great deal of emphasis on determinism and reliability. So, you know, there's some bad things related to current way software is defined and designed in aerospace. This is kind of so as I said, you know, as we said, both Tim and I have worked in aerospace, kind of on the development side of things and also on the cybersecurity testing side of things. The things that I found many things frustrating when I was doing on the development side of things. This is kind of the piece of that list right here. Data validation is guardian against accidental data modification. The design of how software is made to be robust in aviation systems is to guardian against like cosmic ray bit flips single event offsets. So it simple methods like CRC and checksums are sufficient. And also the software that runs it is typically slower and older, more reliable. And therefore, modern data validation methods are going to be very time consuming for those for the hardware involved. There's very little code to guard against unexpected scenarios. If you don't, if it's, if every single line of code costs $100 approximately, probably more nowadays than it was when I found that as statistic, then you're not going to have a bunch of code for guardian against things that the system designers say won't happen. In fact, as Tim says, dead code code that is never expected to be executed is not allowed in DO170AC. There's a lot of complacency because of the level of tests involved, because of the amount of work that goes into designing the software, there's a lot of point of view in the industry that the way we do things, the redundancies that we design in the system, protect us from bad things. And it protects against single event offsets. It doesn't protect against determined and directed attacks. One thing, one piece of software I was working on a while ago had a just a straight up buffer overflow attack against it. And I had to fight fairly hard to actually get it fixed because the incoming data that hit that function with the buffer overflow could only come from a trusted source that would never send more than such amount of data. And there was some sort of like Aaron says a single event offsets, the sort of random bit flip that caused the length field to be long and it was supposed to be. There's a CRC check that would have failed and it wouldn't have even processed the data at all. And they felt that they were completely protected against this scenario, because they just don't have this concept of an adversarial attacker with knowledge of the system, being able to get data into this function, they believe that the only way for data to get this function is from a source that they trust to not send data that's going to cause a buffer overflow. So we're jumping ahead there. The last bullet point on this one is a software is only tested against expected flight configurations. So you will only say, here's, you know, this is what we're going to do for this flight, and that's what we're testing because testing is expensive. There's a lot of tests that are performed as part of this software certification process. So you don't want to run more than necessary. What that means though is that software aviation software and while robust in flight configurations can be extremely brittle. When it is put into conditions that it is not not that are not expected to happen. So here ground maintenance devices. So things actually program the different flight devices. Those are not deal and send me to see rated because they're not flying right there just stay on the ground while the airplane flies. They're covered under some different guidelines about tool development, but they don't have to go if they're not even level certified at something different. So on each box, there's typically a component that will help reprogram that device. That's considered to be deactivated because when the airplane is in flight, you have a signal says, are we are the wheels on the ground or not sometimes called weight on wheels sometimes called weight off wheels make sure you read your documentation very carefully. And whatever signal that is indicates if the that signal is then used in the startup process to make sure that the reprogramming software that component doesn't run. So this is considered to be deactivated. So frequently a physical switch on the piece of hardware they have to switch into some sort of boot mode maintenance mode programming mode. So you have to not only have the weight on your signal gets there also have to have this switch set in the active in a position to boot the piece of hardware into maintenance mode, and then the plane fly if that piece of solid part of it is in the maintenance mode or programming mode you have to switch it back to flight mode before the plane will take off. Right and they'll be like programming sometimes it are built into the wiring harnesses themselves. So when you plug in the harness for reprogram a box that thing has a wire jumper and if that forces this type of mode. So there are some current cybersecurity documents out there do 326, which deal 326 which outlines the activities that should take place at a system and airframe levels is the type of security activities that you should do. If you're developing either a system for an airplane or developing the entire airplane. These are the various testing activities and testing documents that you should create and how to create them deal 356 close a little bit more into the nuts and bolts of what testing should look like. And I like about you 356 the deal 356 does make provisions for the more ad hoc pen test style testing that hackers tend to do the you know the adversarial feeling around trying to see you know scan different systems trying to find some way and some chink in the armor and then exploit and get rid of the system. This is a testing this much. Most testing that you see such as the deal once said make see type testing is extremely formalized every test procedure is written down you do the set of procedures this is your test. That's going to there's additional to the test to pass this mission for the thing if they don't meet the passing mission as a test failed. So 356 does prove to those provisions for the more ad hoc style testing that can be much more useful for security testing, which is like fuzzing, which doesn't really have an analog and like deal and so they see that you can't really formalize a fuzzing procedure. That's where we are right now. We've got some concerns with the current set of it with current way aviation software is currently defined. What do we do. So what do you do about that. Well, Tim and I have a plan. First, you know, as with anything, we've got to figure out what our actual goals are for how to what needs to be secured, what devices need to be secured, and come up with some examples come up with some measures that we can use to reach those goals. It's all very well and good to say, secure the system. But if you don't actually tell people how to go about doing that you're going to end up with a large number of ways to do that, some of which may not be very effective. So the problem is upfront here. Everything is hackable. Right. Give some give enough access motivation time and money, you can get into any type of device, you give us a piece of hardware, and we can get into it. There's a lot of measures you can use to make it more difficult, but depend with large enough playground, you can get into anything you want. So, for goals here, we so for goals here we need to assume that attacker has all the necessary information and resources to do what they want to. We're going to, we're going to design an aircraft to be secure, we need to start from the assumption that the adversary knows what they need to know to get into it. And we need to make sure that we have some way to prove beyond the most up to date way to prove that the software on particular component is 100% correct. If you cannot prove that, then it's going to be impossible to figure out how to get to secure an aircraft. So we need to prevent tax and I will transmission of something malicious. If you know that everything is secure at some point of time, we need to, you know, protect it from going forward, and then put multiple barriers in place also all these different components. So we know that given enough time and money and so on anybody can get into a device if they want to. But it is possible to figure out how to prevent, make an attack practically impossible. And so we limit some of those things so if you know when airplanes on the ground that it has all the correct software and configurations in all the different parts that are on the aircraft, then an attacker would have a limited time frame of the actual flight itself to perform an attack. So that's what we're aiming for. And then to get the idea into aviation that a software component can go from good to bad. Very quickly, just one exploit and all of a sudden this device that was working quickly fine is now no longer working completely fine. It's based on some statistical degradation over time. Now that it just go be good and then be back. So, to define what is important to secure. Here's my list. We have things that are important for flying our craft. And then we have things that are not important for flying the aircraft. These are two device categories. Level, D178 levels, or D178C defines five different levels to how critical software is and the consequences of failures here. For us, there's really only two categories important or not. Because if you leave something that has partial measures in place on the aircraft, then that is a potential point that an attacker could use to pivot to other parts of the aircraft. So, hardware devices are any component that's used to operate the aircraft. Any already device that communicates with those components we've seen instances where you have you may have a level E hardware device that communicates in some way with even a level a hardware device. And this is allowed because that communication has been strictly defined and tested on the piece of the little ASOF where to make sure that it should reject any bad inputs with oftentimes very robust checking and all these bad inputs actually are. But, you know, and from a security context, anywhere that you can touch something important from also needs to be secured, because if you can, you know, have a lower functional lower functional device, lower class of K lower. And you can see down classification device that can can maybe in some way disrupt a higher level, no more critical device and this is something that you have to think about from the security perspective as an attacker using this as a potential pivot to get on to a more critical system. And so, the software that interacts with these components, whether in the fight or on the ground all your ground maintenance software is now used to be considered essentially from a security level. The same as a flight device because these are things that are designed to be able to modify the behavior of these pieces of hardware in fly that are responsible for directly controlling the flight of the aircraft. And that's an important point of what we're defining here, things that we consider flight devices includes the things on the ground that program the device, because those are very critical to making sure that the correct and only the correct components are soft our program. You know, one thing also, we talked about the different components, a different level of components, talking together on the same bus, one very common level a software item on recent aircraft is an operating system running on a particular device. There is a standard called Aaron 673 which defines ways for a partitioned operating system. It's effectively like a virtual machine can have multiple different severity levels running on the same component. So, as we all know in security though, virtual machine escapes are definitely a thing. So if there was an attacker who was able to get into a lower level component, you know that they would be able to from their pivot into the operating system itself, or more critical component if they wanted to. So, what are the different types of devices. How do we go about doing this. Well, we've got a couple different things here. So there's adversarial testing. I choose the word adversarial testing, I don't want to say pen testing because pen testing means different things to different people this is the idea of attacking this, you know, testing the system as an as an attacker what you know you're not. You're strictly checking against a specification. You're actually looking at it from a, if I'm an attacker how could I leverage the system to do something how could I use this protocol to do some all things that you know, security professionals that we do in our jobs. How do we doing these things to now an airplane. Another method is a sense for a pre flight software and configuration authentication. In the flight there was a way to go and check that the system is actually running the software that you think is going to be running actually has an photographic and secure method of validating that the software that's running is the software supposed to be running that your configuration is correct. So, the tips could include like a physically incompatible interfaces on flight systems to make sure that no flight system you can't just plug your iPad into a critical flight system that there's the interface on these flight systems just don't speak these commodity protocols like usb or Bluetooth or Wi-Fi and we'll talk about this a little bit later. I also need to talk about air gaps and anybody nice yes is definitely laughing a little bit right now. But on an airplane with a strictly controlled configuration. You know, air gaps could certainly be a part of the solution for making sure that you can't jump from, you know, the non flight critical portion of the aircraft to the flight critical portion of the aircraft. And that's always as a passenger sitting in the plane. The adversarial testing review and test all interfaces for vulnerabilities, you know, you have to the under you, you can't trust this blindly trust the external inputs into the system. Even if they should only be coming from a system has also been tested the same level, and should only be producing correct outputs for you to consume. You still can't trust this because you can't always trust the system hasn't been compromised in some way. I like to give an example from automotive for that. If you have one component that tells you the break is pressed. And you make sure that the thing that actually generates the signal saying the break is pressed is very works perfectly can't be cracked the thing that interprets that signals work perfectly can't be cracked. It's all well and good but if you then have an entertainment system on the same bus. And the message saying the break is pressed. Well, now you can't trust your inputs can you. Yeah, and testing your protocol stacks and most of your vulnerability. I mean, we've gotten a little bit better but there's been no possible abilities found in TCP IP stacks and other networks stacks over over the years. So you're doing software compile code for vulnerabilities and making sure you're doing like static analysis on the code, not a perfect solution but those catch some things. Secure boot is, I think a fairly critical part of making sure that we can actually trust the software running systems having a good secure boot platform setup. And then we're going to be to preventing at least a, you know, an attacker from modifying the operating system, I should then be modifying the software that runs on this platform because it would be detected. And of course, having multiple layers of protection. Defense in depth has always been one of the strongest things you can do for the security posture of basically anything. So the topic is secure boots one could be talked about for a long time and different people have different definitions of what secure boot means. At a simple level right now. I think what we mean is just that there's a way that the hardware has the ability to use cryptographically secure methods to ensure that only the authorized only authorized software and components are installed and operate on that device. So there's a way to store the keys that should be both this would be immutable. Right and mean and also should not if some once somebody gets in and pulls apart the hardware that they are not able to go in and break out break the secure boot for all the devices. And that is uses perhaps asymmetric cryptography methods and your hash and the user device. So, pre flight software authentication talked about this a little bit earlier, we want to make sure that the before take off that everything on the aircraft is 100% correct and secure and authentic and authentic. So this would be some way, some centralized way to query every single device and find out what software and configuration or body on them. This is already somewhat in existing, you know, before an aircraft flies. This is already somewhat what happens right needed to make sure that only the correct software is on each component so people fly aircraft will already have a list of different software versions that should be running on each component of the airframe. So this isn't, this isn't as outlandish as it sounds. You can use cryptography secure algorithms, no CRCs, no checksums you should be using something like shot to shot three, something better. There should be also the protocol the way the centralized device queries every single component there should be a challenge response protocol here the protocol should also be tested adversarial to make sure there is something that cannot be spoofed. We need to make sure we can prevent replay attacks. So if there is some malicious software malicious component on a box, it should be incapable of, of falsifying the authenticity of that software. And also validate the entire range of memory and flash on each device. You want to make sure that you can like set the length to zero. You want to make sure that you don't have the correct software and the correct configuration and posting for mystery component in the middle and that that gap just isn't checked because it wasn't not to be important. Right, you need to make sure that the entire range is valid. Yeah, physically incompatible interfaces. You know, we're seeing the like the flight crews are there, they have the iPad devices will be there their flight book that has the flight information. And it's always to make sure to one word to help prevent most of the software from being loaded onto these fight critical systems is to make sure that there are physically incompatible interfaces between the non flight systems and the flight cable systems your flight cable systems shouldn't have Bluetooth, they shouldn't have Wi-Fi, they shouldn't have these standardized protocols that everything speaks in a specialized hardwired connections like the connections we have a picture of here, very common in aerospace just make it a lot harder for the flight crew just plug their iPad into a flight critical system. And if you can see on these connectors, some of the important parts of them is that they've actually got different key. So there's usually a bunch of different, you know, a bunch of different pins. So that you have all the necessary signals that you need for a particular connector, but then you there's a lot of different varieties of key, these are five slots, so my four different widths different positions. And the whole idea is that you want to make sure that you cannot connect a component wrong. This is already what's done on an aircraft for connecting all the different flight components. And this is something that we say is necessary when connecting anything to a flight system. So air gaps, as Tim said, everybody who is in ICS is probably laughing when we had that up there before. But the whole point is that an aircraft doesn't change. If it changes, it changes because the design of the aircraft changes, it changes because there was an actual documented and, you know, tested reason for doing so. So designing the system, you should make sure that the flight systems and the non flight systems cannot talk at all. They should be physically separate. We, as I said, virtual machine escapes are definitely a thing should not be running on the same box, they should not be able to even talk on the same bus. So anything that needs, if somebody, you don't want to have to test everything on aircraft, right, you want to make sure you can, you want to try and trim what you need to test because testing is expensive. So something like an entertainment system, maybe somebody doesn't want to go about testing that. Well, that's okay. If you can make sure that that entertainment system can never ever talk to a flight system, which means no common buses. It means that the only thing on the aircraft connected to that entertainment system from the flight components is power. If you need somebody to, it's a crew needs to like disconnect a component, they would need to be able to, you know, toggle the power to that device, instead of actually sending a message to shut down. So some examples of what we've got here. We're going to go through some different categories, areas, three different types of systems and talk about how we would apply these things to ensure that they're secure. And in these cover, this is pretty much the, you know, all the different types of devices that you would have them on aircraft, right, passenger accessible systems, the things that passengers can get access to. So maintenance devices. These are the things that program the different components when the aircraft is on the ground. Usually, a fancy laptop, maybe a robust laptop with some sort of waterproof case and special cables and extra interfaces to talk to the aircraft parts. These need to be adversarial attested. This is should be unsurprising to hear by now. Communications with the different flight devices should require full authentication. And these devices should also have a plan and method to periodically validate that the device itself has not been compromised. As I said, they're typically a regular laptop or some sort of a PC type device. So any of the standard ways to secure a PC, you know, a laptop should be used on these devices to make sure. And then, again, they should be have already not be should have all the different security protections in place. Programming other devices as well as typically, it can happen through there is an airing standard for this as well, although it's optional, not every device implements it. It's called Aaron 615 for data loading. And that can happen over multiple types of device buses such as Aaron 429. And these devices will then usually talk over that. It's kind of a double absurd on one hand, it means it's, you've got to stand away doing things on the other hand, it means that if it simply somebody implements Aaron 429, you potentially be able to go up and program with an unauthenticated device, which is why communication with the flight device should require full you know, back and forth challenge response authentication on both ends. The device should make sure that the programming, the device programming is who it says it is and vice versa. Full mutual, full mutual authentication. That's the term. So passenger sensible systems should either be incapable of connecting to aircraft aircraft systems, not physically connected in any way, not physically sharing any, you know, any piece of hardware. Ideally, not even speaking the same sort of protocols, so they couldn't even accidentally be connected together, and you can't just plug us being our in 429 have it work. They need to be saying as everything else adversarial attested and not have external connectivity that a moral passenger would be able to just plug into and use to have like a USB for charging it should only be for charging only the data lines to be connected should have the need of the data lines to be connected. And so that's the only case where there's an exception then is if this isn't a system if the entertainment system is incapable of being connected to critical flight systems, or to flight systems. Then you could have a USB audio interface on it. Yes. That's the that's the only case where that would be allowed, you would need to make sure that this device cannot talk to anything else. And the whole goal here is to make sure that something can't be done. Something cannot accidentally, or through, you know, through somebody dropping a bad cable somewhere near the airport. And then you have somebody connect something that shouldn't be connected to the air to the flight systems. That's the whole goal here. If somebody is going to try and attack an aircraft. During that would small that limited window of the flight itself we want to make sure that it is incredibly obvious that they're doing something that they shouldn't be doing. And then is very benign. But if they're starting to rip up panels and trying to find the air and fortunately I'm bus somewhere down there. Well, that should hopefully be obvious to some of the other passengers or the crew, and corrective measures can take place. And that's the whole goal here we want to make sure that can't be done accidentally, or on purpose without it being obvious. The flight systems, the slices and themselves we've talked about these quite a bit already. These need to be adversely tested of course we need to make sure that there's multiple levels of protection in the way for anybody who is trying to attack a system that they would need to get through. No consumer interfaces. So, all those flight systems you need to make sure that you do not have the, you don't have the, you know, there's no USB in there. There's no Wi Fi in there. So, iPads as a flight bay are a thing now. And obviously there's an appeal in terms of how easy it is to update. We don't have to carry around stacks and stacks of paper. There's, it's an easy way to store a lot of thing. But that means you've now got a device which is in the cockpit, which is considered a flight critical system which is a consumer device. That gives me some concerns. So I think there needs to be some thought on how to secure that type of system. Maybe it just needs to be not an iPad. Maybe it can be a special purpose device. There's plenty of things out there with an LCD. They can store maps and have a program in them. No consumer interfaces. Yes. So no USB. You wouldn't be able to connect this. You don't want to have somebody accidentally plug in a USB is not supposed to. So, just as a quick summary here. Again, our goals. These are the things that we want to achieve. And I think we have for what we've put in place. Making sure we still have to assume again, at the front, our attacker has everything knows everything. We've talked about providing a way to make sure that the systems can be validated and be correct. And we've talked about the ways that the software and configurations on the different components are correct when the aircraft before the aircraft takes off. We want to limit that potential attack window. We've talked about the ways we can prevent accidental transmission of something malicious to the physical, you know, air gaps, physical disconnects, physically and compatible interfaces. And again, if this is all the goal is make multiple barriers there. Multiple barriers or an attacker would not need to get through. Yeah. And then to the last categories, there's stuff that can affect flight and stuff that can't affect flight. And if I fly doesn't this case mean physical full physical isolation company thing like critical. And so, methods, we've talked about these at length adversarial testing, I believe is a big key part of this. One thing that I guess we didn't really talk about is kind of design standards. It's something that could be addressed as well. And we need to ensure that the software is developed complies with the different record best practice recommendation of how to develop secure software in terms of like program functions that are allowed and such. That's another potential method. This is we are more looking at the fitting things on top of what was there already. But we still do have a few problems that we need to solve. We know so we're not going to try and pretend that we solve everything here. We'd like to think that we saw just significant part of aviation cybersecurity just in this talk. But the few things that we need to think about going forward supply chain security is still a concern. And so, as I said, anything to be hacked. If some as the devices are sitting in storage, an attacker could go in and modify them, they've got plenty of time to go in and modify them, figure out how they work. Either modify the software or just physically physical modifications to the hardware. And how to make sure that that doesn't happen or can't happen is a challenge. So, our communication is also another area where they really address the airplane has a fair bit of our communication that has radio and ESP, you know, whether, etc. This is also something that wasn't addressed by this. What we've been hearing this talk. The flight crew, the pilots training is a significant part of that if there is issues with communications between the aircraft and ground. That's something where training can kick in and deal with the situation. But it is still something that would be. It would improve matters if there was a way to secure the communications. And I also want to talk, think about in the future how often how much change would require something to be retested more, more adversarial testing, what level of change, what type of change. Do 17c defines that for software where different amounts of change are considered to be minor, minor fixes, and they don't have to require a complete redesign of the system. But some level of change does require a complete redesign and retesting the system. So there's, that's something that would need to be looked at in the future. And then there's also the maintenance devices themselves. We talked about how maintenance devices are used to program all the different components on aircraft. This means that would be used to program both flight systems and these air gap non flight systems. So it's, maybe those need to have a slightly different category, you could argue you can put together a committee meeting and argue about lots of this stuff for a while if you want to. But I think that the, what we've given here is a fairly complete approach to address cybersecurity. Any questions. Thank you all so much for your time.
 I'm Aaron Grealius.  I'm a security researcher with Grim.  I'm a cyber physical systems team.  We work on improving the security of embedded devices everywhere.  I've also got a background along background and  embedded software development on critical systems.  The telecom, aerospace,  medical and a bunch of different fields.  My name is Tim Brum.  I run the cyber physical systems team here at Grim.  I've been at Grim for about five years now,  hacking all sorts of different types of embedded systems from aerospace to automotive,  heavy trucking, medical.  Now we're here today to talk about some of  where cybersecurity meets aviation regulations.  I'm going to start by talking about the current status of cybersecurity regulation  and more how software development happens in aerospace.  The current process that we have descends from  the historically how airlines have approached the topic of safety.  Airlines have approached the topic of safety  usually historically from a purely mechanical standpoint.  This part will last for about this long in airplanes.  So that's very placed every so often.  There's maintenance procedures and  everything this direct is to talk about how often these parts need to be replaced based on how on it takes them to fail.  There's things that they test.  Like anywhere you have stresses on a metal joint,  you'll have testing done both visual inspection and other types of testing depending on  circumstances to see if it's starting to fail,  starting to get cracks forming in those areas.  But it's really designed around this concept that  once you make a part, it behaves in some sort of defined way that doesn't change.  Once you design it, do all your fairly rigorous testing that they do  in the airline aerospace industry and install it.  Like it will change in ways they're defined essentially by the physics of the situation.  Stresses on metal, opening and closings of latches and stuff like that.  That have a defined physical characteristic and you can define maintenance procedures  that will detect all of these potential issues on the airplane.  The maintenance procedures you're defined to replace things that you need to replace periodically.  These maintenance procedures are, you can follow it between the commercial aerospace world will be followed.  You may rely on that happening that does happen.  And they do it in places like this.  They have drawers that have labeled places for every bit, every socket, every tool.  It's access controlled.  So you know that when you do your maintenance procedure, there's a procedure for using this size socket  to remove these bolts and you put it back when you're done.  So you don't wind up leaving a socket in an airplane.  They have these fairly strictly defined procedures that you follow  in order to make sure that all of these maintenance is done correctly and done completely.  So that's the kind of history of where we came from.  As far as the current regulations that drive the software development process for our modern aviation software,  that's regulated at least in this country and many other ones,  by something called DO-170AC.  We're not going to go into this too deeply, but knowing how things work right now  and how levels of safety are defined will help us think about  cybersecurity and where, how to go forward with that.  This is developed by RTCA.  It stands for Radio Technical Commissions for Aeronautics,  which I never actually know until I look that up.  It's not super important, it's just an organization that develops a bunch of aviation standards.  And again, these are adopted by FAA in the United States, Transport Canada,  and the European Aviation Safety Agency, EASA.  So what is DO-170AC?  I like to summarize it this way.  You basically tell the FAA, well, a DER, it's the designated representative  that stands in for the FAAs, tell them how you plan on designing, creating,  and testing your software.  And then you go and follow your plan and do those things,  and then you have to prove that you followed your plan.  That's it in a nutshell.  Now, there's a lot more paperwork involved.  There's a lot of checklists you do have to go through and make sure that your plan actually does  identify all of the areas of concern that DO-170AC points out.  And if the DER thinks that anything is lacking in your plan,  they will tell you and help you make sure that it gets revised appropriately.  That's the way things go forward right now.  And as you can see, it's kind of a very water-folly-based model  where you do all of your design upfront.  You create a design, you create a spec, that actual product that implements the design,  that you do testing on it in order to make sure that your  the product you designed actually meets the requirements that the product was supposed to  fulfill.  That is a good point.  The way this does work in practice, it is extremely waterfall.  If there's been attempts to try and figure out how to fit agile methods into this,  but it is very much planned to prove just pretty much in those steps.  And this again comes from that historical background of making mostly mechanical components  where that is how you design them.  You don't do iterative development on a weight usually.  I mean, if there's issues, you'll go back and fix them, of course.  There is no fail fast on making a lot of these mechanical components.  So it's trying to shoehorn software development into how they make mechanical components  for these aircraft.  And has anybody who's been in software development for a while knows that  waterfall has been around for a long time.  The U178C categorizes different levels of software according to the potential consequences  of a failure of that software.  So levels A through E. And basically A means that something catastrophic would happen if  it fails.  Level E means that nothing is going to happen safety-wise.  Maybe your passengers can't watch movies.  That would be a level E software.  The level A is also the highest cost.  It's probably unsurprising.  The last numbers I can find show that it's estimated to be about $100 per line of code  for level A software.  There's not all software on an airplane is level A.  There's usually just a small percentage as possible because of the cost.  But Boeing 787, for example, is estimated to happen between six and seven million lines of code.  So even if it's a small percentage, just the level of certification alone of the software  drives a great deal of cost.  Basically, these go from different levels.  So level A catastrophic software usually software that is level A rated will have autonomous control.  Which means that there's no way to intervene if something fails.  Hence why it's so expensive and so time consuming to develop.  Then they go on both.  Level B would be something where something hazardous could happen.  But also level B will typically allow for pilot intervention.  So it might be something that significantly increases the workload or the challenge of flying the aircraft.  But it would be something that can be addressed by the pilot's pilot training.  Level A and B is usually lost in life.  Like a level A failure was likely to lead to loss of life.  Level B failure is not likely to lead to loss of life or severe injury.  Injury sustained at a level B failure should be minimal.  And then it goes on down from there.  C and D are major, minor impacts to the flight of the aircraft.  Also, so entertainment systems are going to be level E.  Means that there's lower, less regulations and less checklist essentially.  As you go down in level, you have to do less to prove in that proof set.  So in the 178c, code is expensive.  So stuff, especially at the level B or level A is very unlikely to have unused code in it or unnecessary code in it, like a shell onto a system.  It's, you know, actually, in 178c, you're not allowed to have dead code in your design on the system.  So there's a little, because it's so expensive to develop the code, there's usually a minimal amount of code on these systems.  There is extensive testing done for the higher certification levels.  It's at least a significant quantity of testing done.  Pilot training, how to use the software is,  and the other systems are designed for redundancy and safety.  So if you do have a failure, you can use the system to do that.  But if you do have a failure, there should be a redundant system to back up that failure, unless you have a 737 max, but we won't talk about that right now.  Very limited interfaces on these flight critical systems.  They use the differences like R&429.  R&429 is a UR style bus.  You're limited to sending the 32 bits of data at a time.  So there's not really room for buffer overflow here, you don't really have longer messages on top of R&429.  These interfaces are very strictly defined and fairly limited, provide very limited functionality beyond just sending the necessary critical data back and forth on the bus.  Yeah, there's a great deal of emphasis on determinism and reliability.  So, you know, there's some bad things related to current way software is defined and designed in aerospace.  This is kind of so as I said, you know, as we said, both Tim and I have worked in aerospace, kind of on the development side of things and also on the cybersecurity testing side of things.  The things that I found many things frustrating when I was doing on the development side of things. This is kind of the piece of that list right here.  Data validation is guardian against accidental data modification.  The design of how software is made to be robust in aviation systems is to guardian against like cosmic ray bit flips single event offsets.  So it simple methods like CRC and checksums are sufficient.  And also the software that runs it is typically slower and older, more reliable.  And therefore, modern data validation methods are going to be very time consuming for those for the hardware involved.  There's very little code to guard against unexpected scenarios. If you don't, if it's, if every single line of code costs $100 approximately, probably more nowadays than it was when I found that as statistic, then you're not going to have a bunch of code for  guardian against things that the system designers say won't happen. In fact, as Tim says, dead code code that is never expected to be executed is not allowed in DO170AC.  There's a lot of complacency because of the level of tests involved, because of the amount of work that goes into designing the software, there's a lot of point of view in the industry that the way we do things, the redundancies that we design in the system, protect us from bad things.  And it protects against single event offsets. It doesn't protect against determined and directed attacks.  One thing, one piece of software I was working on a while ago had a just a straight up buffer overflow attack against it.  And I had to fight fairly hard to actually get it fixed because the incoming data that hit that function with the buffer overflow could only come from a trusted source that would never send more than such amount of data.  And there was some sort of like Aaron says a single event offsets, the sort of random bit flip that caused the length field to be long and it was supposed to be. There's a CRC check that would have failed and it wouldn't have even processed the data at all.  And they felt that they were completely protected against this scenario, because they just don't have this concept of an adversarial attacker with knowledge of the system, being able to get data into this function, they believe that the only way for data to get this function is from a source that they  trust to not send data that's going to cause a buffer overflow.  So we're jumping ahead there. The last bullet point on this one is a software is only tested against expected flight configurations.  So you will only say, here's, you know, this is what we're going to do for this flight, and that's what we're testing because testing is expensive. There's a lot of tests that are performed as part of this software certification process.  So you don't want to run more than necessary. What that means though is that software aviation software and while robust in flight configurations can be extremely brittle.  When it is put into conditions that it is not not that are not expected to happen.  So here ground maintenance devices. So things actually program the different flight devices. Those are not deal and send me to see rated because they're not flying right there just stay on the ground while the airplane flies.  They're covered under some different guidelines about tool development, but they don't have to go if they're not even level certified at something different.  So on each box, there's typically a component that will help reprogram that device.  That's considered to be deactivated because when the airplane is in flight, you have a signal says, are we are the wheels on the ground or not sometimes called weight on wheels sometimes called weight off wheels make sure you read your documentation very carefully.  And whatever signal that is indicates if the that signal is then used in the startup process to make sure that the reprogramming software that component doesn't run.  So this is considered to be deactivated.  So frequently a physical switch on the piece of hardware they have to switch into some sort of boot mode maintenance mode programming mode. So you have to not only have the weight on your signal gets there also have to have this switch set in the active in a position to boot the piece of hardware into  maintenance mode, and then the plane fly if that piece of solid part of it is in the maintenance mode or programming mode you have to switch it back to flight mode before the plane will take off.  Right and they'll be like programming sometimes it are built into the wiring harnesses themselves. So when you plug in the harness for reprogram a box that thing has a wire jumper and if that forces this type of mode.  So there are some current cybersecurity documents out there do 326, which deal 326  which outlines the activities that should take place at a system and airframe levels is the type of security activities that you should do. If you're developing either a system for an airplane or developing the entire airplane.  These are the various testing activities and testing documents that you should create and how to create them deal 356 close a little bit more into the nuts and bolts of what testing should look like.  And I like about you 356 the deal 356 does make provisions for the more ad hoc pen test style testing that hackers tend to do the you know the adversarial feeling around trying to see you know scan different systems trying to find some way and some chink in the armor  and then exploit and get rid of the system. This is a testing this much. Most testing that you see such as the deal once said make see type testing is extremely formalized every test procedure is written down you do the set of procedures this is your test.  That's going to there's additional to the test to pass this mission for the thing if they don't meet the passing mission as a test failed.  So 356 does prove to those provisions for the more ad hoc style testing that can be much more useful for security testing, which is like fuzzing, which doesn't really have an analog and like deal and so they see that you can't really formalize a fuzzing procedure.  That's where we are right now. We've got some concerns with the current set of it with current way aviation software is currently defined. What do we do.  So what do you do about that. Well, Tim and I have a plan.  First, you know, as with anything, we've got to figure out what our actual goals are for how to what needs to be secured, what devices need to be secured, and come up with some examples come up with some measures that we can use to reach those goals.  It's all very well and good to say, secure the system.  But if you don't actually tell people how to go about doing that you're going to end up with a large number of ways to do that, some of which may not be very effective.  So the problem is upfront here. Everything is hackable. Right.  Give some give enough access motivation time and money, you can get into any type of device, you give us a piece of hardware, and we can get into it.  There's a lot of measures you can use to make it more difficult, but depend with large enough playground, you can get into anything you want.  So, for goals here, we so for goals here we need to assume that attacker has all the necessary information and resources to do what they want to.  We're going to, we're going to design an aircraft to be secure, we need to start from the assumption that the adversary knows what they need to know to get into it.  And we need to make sure that we have some way to prove beyond the most up to date way to prove that the software on particular component is 100% correct.  If you cannot prove that, then it's going to be impossible to figure out how to get to secure an aircraft.  So we need to prevent tax and I will transmission of something malicious. If you know that everything is secure at some point of time, we need to, you know, protect it from going forward, and then put multiple barriers in place also all these different components.  So we know that given enough time and money and so on anybody can get into a device if they want to. But it is possible to figure out how to prevent, make an attack practically impossible.  And so we limit some of those things so if you know when airplanes on the ground that it has all the correct software and configurations in all the different parts that are on the aircraft, then an attacker would have a limited time frame of the actual flight itself to perform an attack.  So that's what we're aiming for.  And then to get the idea into aviation that a software component can go from good to bad. Very quickly, just one exploit and all of a sudden this device that was working quickly fine is now no longer working completely fine.  It's based on some statistical degradation over time. Now that it just go be good and then be back.  So, to define what is important to secure. Here's my list.  We have things that are important for flying our craft. And then we have things that are not important for flying the aircraft. These are two device categories.  Level, D178 levels, or D178C defines five different levels to how critical software is and the consequences of failures here.  For us, there's really only two categories important or not.  Because if you leave something that has partial measures in place on the aircraft, then that is a potential point that an attacker could use to pivot to other parts of the aircraft.  So, hardware devices are any component that's used to operate the aircraft. Any already device that communicates with those components we've seen instances where you have you may have a level E hardware device that communicates in some way with even a level a hardware device.  And this is allowed because that communication has been strictly defined and tested on the piece of the little ASOF where to make sure that it should reject any bad inputs with oftentimes very robust checking and all these bad inputs actually are.  But, you know, and from a security context, anywhere that you can touch something important from also needs to be secured, because if you can, you know, have a lower functional lower functional device, lower class of K lower.  And you can see down classification device that can can maybe in some way disrupt a higher level, no more critical device and this is something that you have to think about from the security perspective as an attacker using this as a potential pivot to get on to a more critical system.  And so, the software that interacts with these components, whether in the fight or on the ground all your ground maintenance software is now used to be considered essentially from a security level.  The same as a flight device because these are things that are designed to be able to modify the behavior of these pieces of hardware in fly that are responsible for directly controlling the flight of the aircraft.  And that's an important point of what we're defining here, things that we consider flight devices includes the things on the ground that program the device, because those are very critical to making sure that the correct and only the correct components are soft our program.  You know, one thing also, we talked about the different components, a different level of components, talking together on the same bus, one very common level a software item on recent aircraft is an operating system running on a particular device.  There is a standard called Aaron 673 which defines ways for a partitioned operating system. It's effectively like a virtual machine can have multiple different severity levels running on the same component.  So, as we all know in security though, virtual machine escapes are definitely a thing. So if there was an attacker who was able to get into a lower level component, you know that they would be able to from their pivot into the operating system itself, or more critical component if they wanted to.  So, what are the different types of devices. How do we go about doing this. Well, we've got a couple different things here.  So there's adversarial testing.  I choose the word adversarial testing, I don't want to say pen testing because pen testing means different things to different people this is the idea of attacking this, you know, testing the system as an as an attacker what you know you're not.  You're strictly checking against a specification. You're actually looking at it from a, if I'm an attacker how could I leverage the system to do something how could I use this protocol to do some all things that you know, security professionals that we do in our jobs.  How do we doing these things to now an airplane.  Another method is a sense for a pre flight software and configuration authentication.  In the flight there was a way to go and check that the system is actually running the software that you think is going to be running actually has an photographic and secure method of validating that the software that's running is the software supposed to be running that your configuration is correct.  So, the tips could include like a physically incompatible interfaces on flight systems to make sure that no flight system you can't just plug your iPad into a critical flight system that there's the interface on these flight systems just don't speak these commodity protocols like usb or Bluetooth or  Wi-Fi and we'll talk about this a little bit later.  I also need to talk about air gaps and anybody nice yes is definitely laughing a little bit right now. But on an airplane with a strictly controlled configuration.  You know, air gaps could certainly be a part of the solution for making sure that you can't jump from, you know, the non flight critical portion of the aircraft to the flight critical portion of the aircraft.  And that's always as a passenger sitting in the plane.  The adversarial testing review and test all interfaces for vulnerabilities, you know, you have to the under you, you can't trust this blindly trust the external inputs into the system.  Even if they should only be coming from a system has also been tested the same level, and should only be producing correct outputs for you to consume. You still can't trust this because you can't always trust the system hasn't been compromised in some way.  I like to give an example from automotive for that. If you have one component that tells you the break is pressed.  And you make sure that the thing that actually generates the signal saying the break is pressed is very works perfectly can't be cracked the thing that interprets that signals work perfectly can't be cracked.  It's all well and good but if you then have an entertainment system on the same bus.  And the message saying the break is pressed. Well, now you can't trust your inputs can you.  Yeah, and testing your protocol stacks and most of your vulnerability. I mean, we've gotten a little bit better but there's been no possible abilities found in TCP IP stacks and other networks stacks over over the years.  So you're doing software compile code for vulnerabilities and making sure you're doing like static analysis on the code, not a perfect solution but those catch some things.  Secure boot is, I think a fairly critical part of making sure that we can actually trust the software running systems having a good secure boot platform setup.  And then we're going to be to preventing at least a, you know, an attacker from modifying the operating system, I should then be modifying the software that runs on this platform because it would be detected.  And of course, having multiple layers of protection.  Defense in depth has always been one of the strongest things you can do for the security posture of basically anything.  So the topic is secure boots one could be talked about for a long time and different people have different definitions of what secure boot means.  At a simple level right now. I think what we mean is just that there's a way that the hardware has the ability to use cryptographically secure methods to ensure that only the authorized only authorized software and components are installed and operate on that device.  So there's a way to store the keys that should be both this would be immutable.  Right and mean and also should not if some once somebody gets in and pulls apart the hardware that they are not able to go in and break out break the secure boot for all the devices.  And that is uses perhaps asymmetric cryptography methods and your hash and the user device.  So, pre flight software authentication talked about this a little bit earlier, we want to make sure that the before take off that everything on the aircraft is 100% correct and secure and authentic and authentic.  So this would be some way, some centralized way to query every single device and find out what software and configuration or body on them. This is already somewhat in existing, you know, before an aircraft flies.  This is already somewhat what happens right needed to make sure that only the correct software is on each component so people fly aircraft will already have a list of different software versions that should be running on each component of the airframe.  So this isn't, this isn't as outlandish as it sounds.  You can use cryptography secure algorithms, no CRCs, no checksums you should be using something like shot to shot three, something better.  There should be also the protocol the way the centralized device queries every single component there should be a challenge response protocol here the protocol should also be tested adversarial to make sure there is something that cannot be spoofed.  We need to make sure we can prevent replay attacks. So if there is some malicious software malicious component on a box, it should be incapable of, of falsifying the authenticity of that software.  And also validate the entire range of memory and flash on each device.  You want to make sure that you can like set the length to zero. You want to make sure that you don't have the correct software and the correct configuration and posting for mystery component in the middle and that that gap just isn't checked because it wasn't  not to be important. Right, you need to make sure that the entire range is valid.  Yeah, physically incompatible interfaces.  You know, we're seeing the like the flight crews are there, they have the iPad devices will be there their flight book that has the flight information.  And it's always to make sure to one word to help prevent most of the software from being loaded onto these fight critical systems is to make sure that there are physically incompatible interfaces between the non flight systems and the flight cable systems your flight cable systems shouldn't  have Bluetooth, they shouldn't have Wi-Fi, they shouldn't have these standardized protocols that everything speaks in a specialized hardwired connections like the connections we have a picture of here, very common in aerospace just make it a lot harder for the flight crew just plug their iPad into a  flight critical system.  And if you can see on these connectors, some of the important parts of them is that they've actually got different key. So there's usually a bunch of different, you know, a bunch of different pins.  So that you have all the necessary signals that you need for a particular connector, but then you there's a lot of different varieties of key, these are five slots, so my four different widths different positions.  And the whole idea is that you want to make sure that you cannot connect a component wrong. This is already what's done on an aircraft for connecting all the different flight components.  And this is something that we say is necessary when connecting anything to a flight system.  So air gaps, as Tim said, everybody who is in ICS is probably laughing when we had that up there before. But the whole point is that an aircraft doesn't change.  If it changes, it changes because the design of the aircraft changes, it changes because there was an actual documented and, you know, tested reason for doing so.  So designing the system, you should make sure that the flight systems and the non flight systems cannot talk at all.  They should be physically separate. We, as I said, virtual machine escapes are definitely a thing should not be running on the same box, they should not be able to even talk on the same bus.  So anything that needs, if somebody, you don't want to have to test everything on aircraft, right, you want to make sure you can, you want to try and trim what you need to test because testing is expensive.  So something like an entertainment system, maybe somebody doesn't want to go about testing that. Well, that's okay.  If you can make sure that that entertainment system can never ever talk to a flight system, which means no common buses. It means that the only thing on the aircraft connected to that entertainment system from the flight components is power.  If you need somebody to, it's a crew needs to like disconnect a component, they would need to be able to, you know, toggle the power to that device, instead of actually sending a message to shut down.  So some examples of what we've got here. We're going to go through some different categories, areas, three different types of systems and talk about how we would apply these things to ensure that they're secure.  And in these cover, this is pretty much the, you know, all the different types of devices that you would have them on aircraft, right, passenger accessible systems, the things that passengers can get access to.  So maintenance devices.  These are the things that program the different components when the aircraft is on the ground.  Usually, a fancy laptop, maybe a robust laptop with some sort of waterproof case and special cables and extra interfaces to talk to the aircraft parts.  These need to be adversarial attested. This is should be unsurprising to hear by now.  Communications with the different flight devices should require full authentication. And these devices should also have a plan and method to periodically validate that the device itself has not been compromised.  As I said, they're typically a regular laptop or some sort of a PC type device. So any of the standard ways to secure a PC, you know, a laptop should be used on these devices to make sure.  And then, again, they should be have already not be should have all the different security protections in place.  Programming other devices as well as typically, it can happen through there is an airing standard for this as well, although it's optional, not every device implements it.  It's called Aaron 615 for data loading.  And that can happen over multiple types of device buses such as Aaron 429.  And these devices will then usually talk over that.  It's kind of a double absurd on one hand, it means it's, you've got to stand away doing things on the other hand, it means that if it simply somebody implements Aaron 429, you potentially be able to go up and program with an unauthenticated device, which is why communication with the flight device should require full  you know, back and forth challenge response authentication on both ends. The device should make sure that the programming, the device programming is who it says it is and vice versa.  Full mutual, full mutual authentication.  That's the term.  So passenger sensible systems should either be incapable of connecting to aircraft aircraft systems, not physically connected in any way, not physically sharing any, you know, any piece of hardware.  Ideally, not even speaking the same sort of protocols, so they couldn't even accidentally be connected together, and you can't just plug us being our in 429 have it work.  They need to be saying as everything else adversarial attested and not have external connectivity that a moral passenger would be able to just plug into and use to have like a USB for charging it should only be for charging only the data lines to be connected should have  the need of the  data lines to be connected. And so that's the only case where there's an exception then is if this isn't a system if the entertainment system is incapable of being connected to critical flight systems, or to flight systems.  Then you could have a USB audio interface on it.  Yes.  That's the that's the only case where that would be allowed, you would need to make sure that this device cannot talk to anything else. And the whole goal here is to make sure that something can't be done.  Something cannot accidentally, or through, you know, through somebody dropping a bad cable somewhere near the airport.  And then you have somebody connect something that shouldn't be connected to the air to the flight systems. That's the whole goal here. If somebody is going to try and attack an aircraft.  During that would small that limited window of the flight itself we want to make sure that it is incredibly obvious that they're doing something that they shouldn't be doing.  And then is very benign. But if they're starting to rip up panels and trying to find the air and fortunately I'm bus somewhere down there. Well, that should hopefully be obvious to some of the other passengers or the crew, and corrective measures  can take place.  And that's the whole goal here we want to make sure that can't be done accidentally, or on purpose without it being obvious.  The flight systems, the slices and themselves we've talked about these quite a bit already. These need to be adversely tested of course we need to make sure that there's multiple levels of  protection in the way for anybody who is trying to attack a system that they would need to get through.  No consumer interfaces. So, all those flight systems you need to make sure that you do not have the, you don't have the, you know, there's no USB in there.  There's no Wi Fi in there. So, iPads as a flight bay are a thing now. And obviously there's an appeal in terms of how easy it is to update.  We don't have to carry around stacks and stacks of paper. There's, it's an easy way to store a lot of thing.  But that means you've now got a device which is in the cockpit, which is considered a flight critical system which is a consumer device.  That gives me some concerns. So I think there needs to be some thought on how to secure that type of system.  Maybe it just needs to be not an iPad. Maybe it can be a special purpose device. There's plenty of things out there with an LCD. They can store maps and have a program in them.  No consumer interfaces. Yes. So no USB. You wouldn't be able to connect this.  You don't want to have somebody accidentally plug in a USB is not supposed to.  So, just as a quick summary here.  Again, our goals.  These are the things that we want to achieve. And I think we have for what we've put in place.  Making sure we still have to assume again, at the front, our attacker has everything knows everything.  We've talked about providing a way to make sure that the systems can be validated and be correct.  And we've talked about the ways that the software and configurations on the different components are correct when the aircraft before the aircraft takes off. We want to limit that potential attack window.  We've talked about the ways we can prevent accidental transmission of something malicious to the physical, you know, air gaps, physical disconnects, physically and compatible interfaces.  And again, if this is all the goal is make multiple barriers there.  Multiple barriers or an attacker would not need to get through.  Yeah.  And then to the last categories, there's stuff that can affect flight and stuff that can't affect flight.  And if I fly doesn't this case mean physical full physical isolation company thing like critical.  And so,  methods, we've talked about these at length adversarial testing, I believe is a big key part of this.  One thing that I guess we didn't really talk about is kind of design standards.  It's something that could be addressed as well.  And we need to ensure that the software is developed complies with the different record best practice recommendation of how to develop secure software in terms of like program functions that are allowed and such.  That's another potential method. This is we are more looking at the fitting things on top of what was there already.  But we still do have a few problems that we need to solve. We know so we're not going to try and pretend that we solve everything here. We'd like to think that we saw just significant part of aviation cybersecurity just in this talk.  But the few things that we need to think about going forward supply chain security is still a concern.  And so, as I said, anything to be hacked. If some as the devices are sitting in storage, an attacker could go in and modify them, they've got plenty of time to go in and modify them, figure out how they work.  Either modify the software or just physically physical modifications to the hardware.  And how to make sure that that doesn't happen or can't happen is a challenge.  So, our communication is also another area where they really address the airplane has a fair bit of our communication that has radio and ESP, you know, whether, etc.  This is also something that wasn't addressed by this.  What we've been hearing this talk.  The flight crew, the pilots training is a significant part of that if there is issues with communications between the aircraft and ground. That's something where training can kick in and deal with the situation.  But it is still something that would be.  It would improve matters if there was a way to secure the communications.  And I also want to talk, think about in the future how often how much change would require something to be retested more, more adversarial testing, what level of change, what type of change.  Do 17c defines that for software where different amounts of change are considered to be minor, minor fixes, and they don't have to require a complete redesign of the system.  But some level of change does require a complete redesign and retesting the system. So there's, that's something that would need to be looked at in the future.  And then there's also the maintenance devices themselves. We talked about how maintenance devices are used to program all the different components on aircraft.  This means that would be used to program both flight systems and these air gap non flight systems.  So it's, maybe those need to have a slightly different category, you could argue you can put together a committee meeting and argue about lots of this stuff for a while if you want to.  But I think that the, what we've given here is a fairly complete approach to address cybersecurity.  Any questions.  Thank you all so much for your time.
DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_0_131.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_132_1583.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_1584_1763.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_1764_1919.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_1920_4643.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_4644_5543.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_5544_7127.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_7128_8483.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_8484_9143.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_9144_10415.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_10416_10787.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_10788_12935.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_12936_13823.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_13824_14735.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_14736_14807.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_14808_15287.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_15288_15359.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_15360_15479.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_15480_15743.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_15744_15863.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_15864_15995.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_15996_16895.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_16896_17231.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_17232_17339.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_17340_17399.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_17400_17471.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_17472_28967.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_28968_29051.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_29052_29183.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_29184_30251.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_30252_30983.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_30984_34355.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_34356_34691.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_34692_35099.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_35100_35255.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_35256_35615.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_35616_40307.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_40308_40583.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_40584_41087.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_41088_41351.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_41352_41483.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_41484_43379.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_43380_48311.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_48312_51275.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_51276_53699.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_53700_56255.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_56256_56483.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_56484_56999.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_57000_60227.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_60228_63911.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_63912_66359.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_66360_66443.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_66444_68111.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_68112_68639.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_68640_73739.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_73740_73859.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_73860_74015.png DEF_CON_Safe_Mode_Aerospace_Village_-_Cornelius__B_nPx1wRgoFeA_74016_74152.png