start	end	text
4970	10270	I'm Aaron Grelias. I'm a security researcher with Grimm. I'm on the cyber physical systems team.
10270	17870	We work on improving the security of embedded devices everywhere. I've also got a background,
18570	23510	a long background in embedded software development on critical systems,
23510	29310	the telecom, aerospace, medical, and a bunch of different fields.
30550	35730	My name is Tim Brown. I run the cyber physical systems team here at Grimm. I've been at Grimm
35730	41150	for about five years now, hacking all sorts of different types of embedded systems from
41150	45230	aerospace to automotive, heavy trucking, medical.
46710	52510	And we're here today to talk about some of where cybersecurity meets aviation regulations.
65510	70890	I'm going to start by talking about the current status of cybersecurity regulation.
70890	76570	And more how software development happens in aerospace.
78270	85510	The current process that we have descends from the, historically, how airlines have
85510	91650	approached the topic of safety. Airlines have approached the topic of safety,
91650	98370	usually, historically, from a purely mechanical standpoint. This part will last for about this
98370	103090	long in airplanes. It has to be replaced every so often. There's maintenance procedures and
103990	108010	airworthiness directives that talk about how often these parts need to be replaced based on
108010	114330	how long it takes them to fail. There's things that they test, like anywhere you have stresses
114330	119890	on a metal joint, you'll have testing done, both visual inspection and other types of testing,
119890	124150	depending on circumstances, to see if it's starting to fail, if it's starting to get
124150	130650	cracks forming in those areas. But it's really designed around this concept that
131330	138630	once you make a part, it behaves in some sort of defined way that doesn't change. Once you design
138630	144370	it, do all your fairly rigorous testing that they do in the airline, the aerospace industry,
144370	149750	and install it, it will change in ways that are defined, essentially, by the physics of the
149750	157430	situation. Stresses on metal, opening and closings of latches, and stuff like that,
157430	163770	that have a defined physical characteristic. And you can define maintenance procedures that will
163770	169350	detect all of these potential issues on the airplane. Maintenance procedures are defined
169350	174270	to replace things that need to be replaced periodically. These maintenance procedures
174270	183190	you can follow in the commercial aerospace world will be followed. They rely on that happening,
183190	190250	that does happen. And they do it in places like this. They have drawers that have
190250	197970	labeled places for every bit, every socket, every tool. It's access controlled. So you know that
197970	203490	when you do your maintenance procedure, there's a procedure for using this size socket to remove
203490	208550	these bolts and you put it back when you're done. So you don't wind up leaving a socket in an
208550	214310	airplane. They have these fairly strictly defined procedures that you follow in order to make sure
214310	225430	that all these maintenance is done correctly and done completely. So that's the kind of history
225430	232550	of where we came from. As far as the current regulations that drive the software development
232550	238370	process for modern aviation software, that's regulated at least in this country and many
238870	245930	other ones by something called DO-178C. We're not going to go into this too deeply, but
247390	253970	knowing how things work right now and how levels of safety are defined will help us think about
253970	261510	cybersecurity and how to go forward with that. This is developed by RTCA. It stands for Radio
261510	267530	Technical Commissions for Aeronautics, which I never actually knew until I looked that up.
267530	271850	It's not super important. It's just an organization that develops a bunch of aviation standards.
274350	281190	And again, these are adopted by FAA in the United States, Transport Canada, and European Aviation
281190	291110	Safety Agency, EASA. So what is DO-178C? I like to summarize it this way. You basically tell
291110	298490	the FAA... well, a DER is the designated representative that stands in for the FAA.
298490	306050	Tell them how you plan on designing, creating, and testing your software. And then you go and
306050	309870	follow your plan and do those things. And then you have to prove that you followed your plan.
309870	316050	That's it in a nutshell. Now there's a lot more paperwork involved. There's a lot of checklists
316050	321090	you do have to go through and make sure that your plan actually does identify all the areas of
321090	329870	concern that DO-178C points out. And if the DER thinks that anything is lacking in your plan,
329870	335850	they will tell you and help you make sure that it gets revised appropriately.
336010	341090	That's the way things go forward right now. And as you can see, it's kind of a very
341090	347550	waterfall-y based model where you do all your design up front, you create a design,
347550	353130	you create a spec, the actual product that implements the design, then you do testing on it
353130	362350	in order to make sure that the product design actually meets the requirements that
362350	370050	the product was supposed to fulfill. That is a good point. The way this does work in practice,
370050	376110	it is extremely waterfall. There have been attempts to try and figure out how to fit
376110	383210	Agile methods into this, but it is very much plan, do, prove. Just pretty much in those steps.
383450	388530	And this again comes from that historical background of making mostly mechanical
388530	394330	components where that is how you design them. You don't do iterative development on,
395150	399970	you know, a weight usually. I mean, if there's issues, you'll go back and fix them of course,
399970	403730	but like you don't really do, you know, there is no fail fast on making a lot of these
403730	408730	mechanical components. So it's trying to shoehorn software development
409250	414150	into how they make mechanical components for these aircraft.
414370	418330	And as anybody who's been in software development for a while knows that
418330	426650	waterfall has been around for a long time. The DO-178C categorizes different levels of software
427330	432230	according to the potential consequences of a failure of that software.
433090	439150	So levels A through E, and basically A means that something catastrophic would happen
439150	446670	if it fails. Level E means that nothing is going to happen safety wise, you know,
446670	452790	maybe the passengers can't watch movies, right? That would be a level E software.
453530	457950	The level A is also the highest cost. This is probably unsurprising.
461230	467990	The last numbers I can find show that it's estimated to be about $100 per line of code
467990	475310	for level A software. They're not all software on an airplane is level A. It's usually just as
475310	480970	small percentage as possible because of the cost. But Boeing 787, for example,
480970	486490	is estimated to have between 6 and 7 million lines of code. So even if it's a small percentage,
486490	492610	just the level of certification alone of the software drives a great deal of cost.
493470	498950	Basically, these go from different levels. So level A, catastrophic software, usually
498950	505530	software that is level A rated will have autonomous control, which means that there's
505530	512430	no way to intervene if something fails, hence why it's so expensive and so time consuming to develop.
512430	518350	Then they go on both. Level B would be something where something hazardous could happen,
518350	525310	but also level B will typically allow for pilot intervention. So it might be something that
526150	530650	significantly increases the workload or the challenge of flying the aircraft,
530650	536250	but it would be something that can be addressed by the pilot training.
536250	543830	Level A and B is usually loss of life. A level A failure was likely to lead to loss of life.
543830	550450	Level B failure is not likely to lead to loss of life or severe injury.
551030	555330	Injury sustained in a level B failure should be minimal.
557130	564390	And then it goes on down from there. C and D are major minor impacts to the flight of the aircraft.
567750	572950	Also, so entertainment systems are going to be level E, means that there's
573530	579490	lower, less regulations and less checklists, essentially. As you go down in level,
579490	583630	you have to do less to prove in that proof step.
587100	594360	In DO-178C, code is expensive. So stuff, especially if it's a level B or level A,
594360	602080	very unlikely to have unused code in it or unnecessary code in it, like a shell onto a
602080	617280	system. DO-178A, you're not allowed to have dead code in your design on the system.
617280	621540	Because it's so expensive to develop the code, there's usually a minimal amount of code
621540	628640	on these systems. There is extensive testing done for the higher certification levels.
628640	635600	There's at least a significant quantity of testing done. Pilot training on how to use the software
637180	642040	is... the systems are designed for redundancy and safety. So if you do have a failure,
642040	648600	there should be a redundant system to back up that failure. Unless you have a 737 MAX,
648600	656120	we won't talk about that right now. Very limited interfaces on these flight-critical systems.
656220	663200	They use interfaces like RN429. RN429 is a UART-style bus. You're limited to sending
664120	670420	32 bits of data at a time. There's not really room for buffer overflow here. You don't really
670420	678180	have longer messages on top of RN429. These interfaces are very strictly defined and fairly
678600	682920	provide very limited functionality beyond just sending the necessary critical data
682920	689320	back and forth on the bus. There's a great deal of emphasis on determinism and reliability.
694300	704320	So there's some bad things related to the current way software is defined and designed
704960	711560	in aerospace. This is kind of... so as I said, you know, as we said, both Tim and I have worked
711560	718320	in aerospace kind of on the development side of things and also on the cybersecurity testing side
718320	726000	of things. The things that... I found many things frustrating when I was doing on the development
726000	733120	side of things. This is kind of the... a piece of that list right here. Data validation is guarding
733120	742140	against accidental data modification. The design of how software is made to be robust in aviation
742140	751220	systems is guarding against like cosmic rate bit flips, single event upsets. So simple methods like
751220	757840	CRCs and checksums are sufficient. And also the software that runs it is typically slower and
757840	766360	older, more reliable, and therefore modern data validation methods are... can be very time consuming
766360	772320	for those... for the hardware involved. There's very little code to guard against unexpected scenarios.
772320	780140	If you don't... if it's... if every single line of code costs a hundred dollars approximately,
780140	786810	probably more nowadays than it was when I found that statistic, then you're not going to have a
786810	792870	code for guarding against things that the system designers say won't happen. In fact, as Tim says,
792870	798790	dead code, code that is never expected to be executed, is not allowed in DO-178C.
800470	805130	The... there's a lot of complacency. Because of the level of tests involved, because of the amount
805130	811410	of work that goes into designing the software, there's a lot of point of view in the industry
811410	818430	that the way we do things, the redundancies that we design into the system, protect us from bad
818430	825690	things. And it protects against single event upsets. It doesn't protect against determined
825690	834790	and directed attacks. One thing... one piece of software I was working on a while ago had a... just
835050	841110	a straight-up buffer overflow attack against it. And I had to fight fairly hard to actually get it
841110	849010	fixed, because the incoming data that hit that function with the buffer overflow could only come
849010	856350	from a trusted source that would never send more than such amount of data. And if there was some
856350	861610	sort of, like Aaron says, a single event upset, a sort of random bit flip that caused the length
861610	867310	field to be longer than it was supposed to be, there's a CRC check that would have failed, and
867310	871390	wouldn't have even processed the data at all. So they felt that they were completely protected
871390	878530	against this scenario, because they just don't have this concept of an adversarial attacker with
878530	884750	knowledge of the system being able to get data into this function. They believe that the only
884750	891630	way for data to get into this function is from a source that they trust to not send data that's
891630	897830	going to cause a buffer overflow. So Tim's kind of jumping ahead there. That last bullet point on
897830	903550	this one is software is only tested against expected flight configurations. So you will only
903550	908570	say, here's, you know, this is what we're going to do for this flight, and that's what we're testing,
908570	913670	because testing is expensive. There's a lot of tests that are performed as part of this software
913670	919450	certification process. You don't want to run more than necessary. What that means, though, is that
920230	926210	software, aviation software, while robust in flight configurations, can be extremely brittle
926970	933510	when it is put into conditions that it is not, that are not expected to happen.
934410	938510	Some other things here, ground maintenance devices, so things that actually program
938510	946110	the different flight devices, those are not D1C rated, because they're not flying, right?
946110	950830	They just stay on the ground while the airplane flies. They're covered under some different
950830	955910	guidelines about tool development, but you don't have to go, they're not even
955910	962410	leveling certified, it's something different. Maintenance software, so on each box, there's
962410	968810	typically a component that will help reprogram that device. That's considered to be deactivated,
968810	975610	because when the airplane is in flight, you have a signal that says, are we, are the wheels on the
975610	982070	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.
983430	993890	And whatever signal that is, indicates if the, that signal is then used in the startup process
993890	999290	to make sure that the reprogramming software, that component, doesn't run. So this is considered to be
999290	1004790	deactivated. There's also frequently a physical switch on the piece of hardware they have to
1004790	1010570	switch into some sort of boot mode, maintenance mode, programming mode. So you have to not only
1010570	1015950	have the weight on wheels signal, but you also have to have this switch set in the
1016710	1023510	activated position to boot the piece of hardware into the maintenance mode. And then the plane
1023510	1029010	won't fly if that piece of hardware is in its maintenance mode or programming mode. You have to
1029010	1034430	switch it back to flight mode before the plane will take off. Right, and it'll be like programmed
1034430	1039650	sometimes that are built into the wiring harnesses themselves. So when you plug in the harness for
1040270	1045670	reprogramming a box, that thing has a wire jumper in it that forces this type of mode.
1050090	1056830	So there are some current cybersecurity documents out there, DO-326, which
1061550	1073550	DO-326, which outlines the activities that should take place at a system and airframe
1073550	1079610	levels. These are the type of security activities that you should do if you're developing either a
1079610	1085410	system for an airplane or developing the entire airplane. These are the various testing activities
1085410	1092830	and testing documents that you should create and how to create them. DO-356 goes a little bit more
1092830	1100070	into the nuts and bolts of what testing should look like. Something I like about DO-356 is DO-356
1100070	1107390	does make provisions for the more ad hoc pentest style testing that hackers tend to do. You know,
1107390	1114610	the adversarial feeling around trying to see, you know, scan different systems, trying to find some
1114610	1120310	way and some chink in the armor that you can then exploit into the system. This is a testing that's
1121010	1127470	much... most testing that you see, especially the DO-178C type testing, is extremely formalized.
1127470	1132390	Every test procedure is written down. You do this set of procedures. This is your test.
1132390	1137170	That's going to... there's conditions to pass. There's conditions for... and if they don't meet
1137170	1143350	the passing conditions, the test failed. DO-356 does provide those provisions for the more ad hoc
1143350	1148450	style testing that can be much more useful for security testing. Provisions for things like
1148450	1154850	fuzzing, which doesn't really have an analog in like DO-178C, but you can't really formalize a
1154850	1165450	fuzzing procedure. So that's where we are right now. We've got some concerns with the current
1166330	1172990	way aviation software is currently defined. What do we do? So what do we do about that? Well,
1172990	1181050	Tim and I have a plan. First, you know, as with anything, we've got to figure out what our actual
1181050	1187830	goals are for how to... what needs to be secured, what devices need to be secured, and come up with
1187830	1192010	some examples, come up with some measures that we can use to reach those goals. It's all very well
1192010	1198610	and good to say secure the system, but if you don't actually tell people how to go about doing that,
1198610	1205030	you're going to end up with a large number of ways to do that, some of which may not be very effective.
1208320	1216120	So the problem is up front here, everything is hackable, right? Give some... give enough access,
1216120	1221720	motivation, time, and money. You can get into any type of device. You give us a piece of hardware,
1221720	1227660	and we can get into it. There's a lot of measures you can use to make it more difficult,
1228220	1236240	but depend... with a large enough playground, you can get into anything you want.
1242270	1250570	So for goals here, we... so for goals here, we need to assume that attacker has all the necessary
1250570	1255650	information and resources to do what they want to. If we're going to... if we're going to design
1256450	1261890	an aircraft to be secure, we need to start from the assumption that the adversary knows
1261890	1269850	what they need to know to get into it. We need to make sure that we have some way to prove beyond
1270990	1278850	the most up-to-date way to prove that the software on a particular component is 100% correct. If you
1278850	1286210	cannot prove that, then it's going to be impossible to figure out how to get to secure an aircraft.
1288230	1293790	We need to prevent accidental transmission of something malicious. If you know that everything
1293790	1298030	is secure at some point in time, you need to, you know, protect it from going forward,
1298030	1302250	and then put multiple barriers in place also to all these different components.
1302970	1309850	We know that given enough time and money and so on, anybody can get into a device if they want to.
1309850	1318050	But it is possible to figure out how to prevent, make an attack practically impossible
1318730	1323290	if you limit some of those things. So if you know when an airplane is on the ground,
1323290	1328710	that it has all of the correct software and configurations in all of the different parts
1328710	1334710	that are on the aircraft, then an attacker would have a limited time frame of the actual flight
1334710	1340350	itself to perform an attack. So that's what we're aiming for.
1340650	1351470	And also aiming to get the idea into aviation that a software component can go from good
1351760	1359350	to bad very quickly. Just one exploit and all of a sudden this device that was working completely
1359350	1365650	fine is now no longer working completely fine. And it's not based on some statistical
1366610	1371510	degradation over time. Now that can just go be good and then be bad.
1375910	1383130	So to define what is important to secure, here's my list. We have things that are important for
1383130	1387890	flying an aircraft. And then we have things that are not important for flying the aircraft.
1387890	1397470	These are two device categories. The level D-178C defines five different levels
1400470	1405370	to how critical software is and the consequences of failures here.
1405530	1411450	For us, there's really only two categories, important or not. Because if you leave something
1411450	1416790	that has partial measures in place on the aircraft, then that is a potential point that
1416790	1421250	an attacker could use to pivot to other parts of the aircraft.
1428730	1434570	So flight devices are any component that's used to operate the aircraft.
1435310	1441450	Any or any device that communicates with those components. We've seen instances where you have,
1441450	1447930	you may have a level E hardware device that communicates in some way with even a level A
1447930	1454110	hardware device. And this is allowed because that communication has been
1454110	1459690	strictly defined and tested on the piece of hardware, the level A software, to make sure
1459690	1467910	that it should reject any bad inputs with oftentimes not very robust checking on what
1467910	1475890	these bad inputs actually are. But from a security context, anywhere that you can touch something
1475890	1483210	important from, also needs to be secured. Because if you can, you know, have a lower functional,
1483210	1487650	lower functioning device, lower classification, lower DO1s, then you see a DAL classification
1487650	1495130	device that can maybe in some way disrupt a higher level, more critical device. And this
1495130	1499050	is something that you have to think about from the security perspective as an attacker,
1499050	1504230	using this as a potential pivot to get onto a more critical system.
1505950	1510610	And also any device or software that interacts with these components, whether in the flight or
1510610	1514950	on the ground, all your ground maintenance software, is now needs to be considered essentially
1514950	1520730	from a security level, the same as a flight device. Because these are things that are designed to be
1520730	1527030	able to modify the behavior of these pieces of hardware that are responsible for
1527030	1533850	directly controlling the flight of the aircraft. I think that's an important point of what we're
1533850	1539970	defining here. Things that we consider flight devices includes the things on the ground that
1539970	1548310	program the device. Because those are very critical to making sure that the correct and
1548310	1556550	only the correct components are programmed. You know, one thing also, Tim talked about the
1556550	1562550	different components, different level of components talking together on the same bus.
1562550	1570050	One very common level A software item on recent aircraft is an operating system
1570510	1575670	running on a particular device. There is a standard called RX-653, which defines
1576790	1582990	ways for a partitioned operating system that's effectively like a virtual machine,
1582990	1590530	can have multiple different severity levels running on the same component.
1591250	1597430	So as we all know, in security though, virtual machine escapes are definitely a thing. So if
1597430	1601890	there was an attacker who was able to get into a lower level component, you know that they would
1601890	1608530	be able to, from there, pivot into the operating system itself, or a more critical component if
1608530	1619280	they wanted to. So that's our devices. How do we go about doing this? Well, we've got a couple
1619280	1628920	different things here. So there's adversarial testing. I choose the word adversarial testing
1628920	1632200	because I don't want to say pentesting, because pentesting means different things to different
1632200	1641380	people. This is the idea of testing the system as an attacker would. You're no longer just
1641380	1647280	strictly checking against a specification. You're actually looking at it from, if I'm an attacker,
1647280	1651920	how could I leverage this system to do something? How could I use this protocol
1652540	1657700	to do something? All the things that, you know, security professionals that we do in our jobs,
1657700	1661600	how do we, you know, doing these things to now an airplane?
1663180	1668120	Another method is some sort of pre-flight software and configuration authentication.
1668840	1674760	If before every flight there was a way to go and check that the system is actually running
1674760	1678220	the software that you think is going to be running, actually has a cryptographically
1678220	1683160	secure method of validating that the software that's running is the software that's supposed
1683160	1689580	to be running, that your configuration is correct. Other methods could include like
1689580	1694760	physically incompatible interfaces on flight systems to make sure that no flight system,
1694760	1701440	you can't just plug your iPad into a critical flight system, that there's the interface on
1701440	1707220	these flight systems, just, you know, they don't speak these commodity protocols like USB or
1707220	1712720	Bluetooth or Wi-Fi. We'll talk about this a little bit later. We also need to talk about
1713280	1719420	air gaps. I know anybody in ICS is definitely laughing a little bit right now, but on an
1719420	1725240	airplane with a strictly controlled configuration, you know, air gaps could certainly be a part of
1725240	1731140	the solution for making sure that you can't jump from, you know, the non-flight critical portion
1731140	1736700	of the aircraft to the flight critical portion of the aircraft, at least as a passenger sitting
1736700	1744600	in the plane. Now the adversarial testing, you know, review and test all interfaces for
1744600	1751740	vulnerabilities. You know, you have to, you can't trust, just blindly trust the external
1751740	1756980	inputs into the system, even if they should only be coming from a system that's also been tested
1756980	1763260	in the same level and should only be producing correct outputs for you to consume, you still
1763260	1769060	can't trust this because you can't always trust that the system hasn't been compromised in some way.
1769500	1777080	I'd like to give an example from automotive for that. If you have one component that tells you
1777080	1782600	the brake is pressed and you make sure that the thing that actually generates the signal
1782600	1786620	saying the brake is pressed works perfectly, can't be
1786620	1790860	cracked, the thing that interprets that signal works perfectly, can't be cracked,
1790860	1794120	it's all well and good, but if you then have an entertainment system on the same bus
1794660	1801480	and that sends a message saying the brake is pressed, well, now you can't trust your inputs, can you?
1804400	1808680	Yeah, and testing your protocol stacks and milestones for vulnerability. I mean, we've
1809400	1814760	gotten a little bit better, but there's been lots of vulnerabilities found in TCP IP stacks and other
1814760	1821300	network stacks over the years. Reviewing the software and compile code for vulnerabilities,
1821300	1827060	making sure you're doing static analysis on the code, not a perfect solution, but it does catch
1827060	1835500	some things. Secure boot is, I think, a fairly critical part of making sure that we can actually
1835500	1843180	trust the software running on the systems. Having a good, secure boot platform set up could go a
1843180	1850120	very long way to preventing at least an attacker from modifying the operating system that should
1850120	1856440	then be modifying the software that runs on this platform because it should be detected.
1856440	1861860	And, of course, having multiple layers of protection. Defense in depth has always been
1861860	1867520	one of the strongest things you can do for the security posture of basically anything.
1869120	1874320	The topic of secure boot is one that could be talked about for a long time and different people
1874320	1881960	have different definitions of what secure boot means. At a simple level right now, I think what
1881960	1886520	we mean is just that there's a way that the hardware has the ability to use cryptographically
1886520	1895120	secure methods to ensure that only authorized software and components are installed and
1895120	1904060	operating on that device. And a way to store the keys that should be immutable.
1905220	1915140	Right. And also, once somebody gets in and pulls apart the hardware that they are not able to go in
1915140	1923220	and break out, break the secure boot for all of the devices. Right. Something that is,
1923780	1930280	uses perhaps asymmetric cryptography methods and secure hashing to be used for device.
1933720	1937980	So pre-flight software authentication, talked about this a little bit earlier.
1937980	1944440	We want to make sure that the before takeoff that everything on the aircraft is 100% correct
1944440	1952300	and secure and authentic. So this would be some way, some centralized way to query every single
1952300	1957320	device and find out what software and configuration are running on them. This is already somewhat
1957880	1966300	in existing, you know, before an aircraft flies, this is already somewhat what happens, right? We
1966300	1972800	need to make sure that only the correct software is on each component. So people who fly aircraft
1972800	1977900	will already have a list of different software versions that should be running on each component
1977900	1985740	of the aircraft. So this isn't as outlandish as it sounds. You can use cryptographic and secure
1985740	1993680	algorithms, no CRCs, no checksums. You should be using something like SHA-2, SHA-3, something better.
1994100	1999220	And there should be also the protocol, the way the centralized device queries every single
1999220	2004920	component, there should be a challenge response protocol here. The protocol should also be tested
2004920	2009740	adversarially to make sure there is something that cannot be spoofed. We need to make sure
2009740	2015740	we can prevent replay attacks. So if there is some malicious software, malicious component on a box,
2015740	2023260	it should be incapable of falsifying the authenticity of that software.
2023260	2030180	You can also validate the entire range of memory and flash on each device. You want to make sure
2030180	2035480	that you can't set the length to zero. You want to make sure that you don't have the correct software
2035480	2039860	and the correct configuration and put some sort of mystery component in the middle and that
2039860	2045640	that gap just isn't checked because it wasn't thought to be important, right? You need to
2045640	2057180	make sure that the entire range is validated. Yeah, physically incompatible interfaces,
2057810	2064280	you know, we're seeing that like the flight crews, they have the iPad devices that will be there,
2064280	2072020	their flight book that has the flight information. One of the ways to make sure to, one order to help
2072020	2076460	prevent malicious software from being loaded onto these flight critical systems is to make sure that
2076460	2082700	there are physically incompatible interfaces between the non-flight systems and the flight
2082700	2088080	capable systems. So your flight cable systems shouldn't have USB, they shouldn't have Bluetooth,
2088080	2093580	they shouldn't have Wi-Fi, they shouldn't have these standardized protocols that everything
2093580	2099180	speaks, you know, specialized hardwired connections like the connections we have a picture of here,
2099180	2104740	very common in aerospace, just make it a lot harder for the flight crew to just plug their iPad
2104740	2112000	into a flight critical system. And if you can see on these connectors, some of the important
2112000	2116620	parts of them is that they've actually got different keying. So there's usually a bunch
2116620	2121240	of different, you know, a bunch of different pins so that you have all the necessary signals that
2121240	2126020	you need for a particular connector. But then you, there's a lot of different varieties of
2126020	2130460	keying. Some have five slots, some have four, different widths, different positions.
2130600	2135820	And the whole idea is that you want to make sure that you cannot connect a component wrong.
2135820	2139460	This is already what's done on an aircraft for connecting all the different flight components.
2139460	2145940	And this is something that we say is necessary when connecting anything to a flight system.
2150040	2156100	So air gaps, as Tim said, everybody who's in ICS is probably laughing when we had that out
2156100	2161600	there before. But the whole point is that an aircraft doesn't change. If it changes,
2161600	2166320	it changes because the design of the aircraft changes. It changes because there was an actual
2166320	2173360	documented and, you know, tested reason for doing so. So designing the system,
2173360	2180300	you should make sure that the flight systems and the non-flight systems cannot talk at all.
2182280	2187900	They should be physically separate. We, as I said, virtual machine escapes are definitely a thing.
2187900	2192020	You should not be running on the same box. They should not be able to even talk on the same bus.
2193300	2199140	So anything that needs, if somebody, you don't want to have to test everything on an aircraft,
2199140	2207560	right? You want to make sure you can, you want to try and trim what you need to test because
2207560	2213200	testing is expensive. So something like an entertainment system, maybe somebody doesn't
2213200	2218860	want to go about testing that. Well, that's okay. If you can make sure that that entertainment
2218860	2226740	system can never ever talk to a flight system, which means no common buses. It means that the
2226740	2232160	only thing on the aircraft connected to that entertainment system from the flight components
2232160	2238180	is power. If you need somebody to, if the crew needs to like disconnect a component, they would
2238180	2244440	need to be able to, you know, toggle the power to that device instead of actually sending a message
2244440	2259510	to shut down. So some examples of what we've got here. We're going to go through some different
2259510	2264850	categories, three different types of systems and talk about how we would apply these things to
2264850	2273170	ensure that they're secure. Maintenance. In these cover, this is pretty much the, you know, all the
2273170	2278010	different types of devices that you would have on an aircraft, right? Passenger accessible systems,
2278010	2288620	things that passengers can get access to and so on. So maintenance devices. These are the things
2288620	2295180	that program the different components when the aircraft is on the ground. They're usually a fancy
2295180	2300440	laptop, maybe a robust laptop with some sort of waterproof case and special cables and extra
2300440	2310180	interfaces to talk to the aircraft parts. These need to be adversarially tested. This is, should
2310180	2316280	be unsurprising to hear by now. Communications with the different flight devices should require
2316280	2323000	full authentication and these devices should also have a plan and method to periodically validate
2323000	2330320	that the device itself has not been compromised. As I said, they're typically a regular laptop
2330320	2338900	or some sort of PC type device. So any of the standard ways to secure a PC, you know, a laptop
2338900	2346040	should be used on these devices to make auditing. They should have auditing on, they should have
2346830	2353900	all the different security protections in place. Programming other devices as well,
2353900	2358600	as typically it can happen to, there is an ERIN standard for this as well, although it's optional.
2358600	2364880	Not every device implements it. It's called ERIN 615 for data loading and that can happen over
2364880	2373320	multiple types of device buses such as ERIN 429. These devices will then usually talk over that.
2373320	2378400	It's kind of a double-edged sword. On one hand, it means you've got a standard way of doing things.
2378400	2383880	On the other hand, it means that if somebody implements ERIN 429, you potentially be able
2383880	2388620	to go up and program with an unauthenticated device, which is why communication with the
2388620	2395760	flight device should require full back and forth challenge response authentication on both ends.
2395940	2401620	The device should make sure that the device programming it is who it says it is and vice
2401620	2407800	versa. Full mutual authentication. That's the term.
2411040	2418100	So passenger accessible systems should either be incapable of connecting to aircraft systems,
2418100	2425120	not physically connected in any way, not physically sharing any piece of hardware,
2427400	2431960	ideally not even speaking the same sort of protocols so they couldn't even accidentally
2431960	2437360	be connected together. You can't just plug USB into ERIN 429 and have it work.
2437980	2444040	Or they need to be same as everything else adversarial tested and not have external
2444040	2451280	connectivity that a normal passenger would be able to just plug into and use. If you have
2451660	2455300	a USB for charging, it should only be for charging. Only the data lines should be
2455300	2462500	connected. It shouldn't have any of the... you should be capable of passing data back and forth.
2465320	2470720	The only case where there's an exception then is if this isn't a system, if the entertainment
2470720	2476760	system is incapable of being connected to critical flight systems or to flight systems,
2477900	2481660	then you could have a USB audio interface on it.
2481660	2482480	Yes.
2482740	2488180	But that's the only case where that would be allowed. You would need to make sure that this
2488180	2492380	device cannot talk to anything else. And the whole goal here is to make sure that something
2492380	2503160	can't be done, something cannot accidentally or through somebody dropping a bad cable somewhere
2503160	2510200	near the airport, have somebody connect something that shouldn't be connected to the flight systems.
2510200	2516540	That's the whole goal here. If somebody is going to try and attack an aircraft
2517560	2521940	during that small, that limited window of the flight itself, we want to make sure
2521940	2527200	that it is incredibly obvious that they're doing something that they shouldn't be doing.
2527360	2533620	So just plugging the USB in is very benign. But if they're starting to rip up panels and trying
2533620	2539700	to find the 429 bus somewhere down there, well, that should hopefully be obvious to
2539700	2545320	some of the other passengers or the crew and corrective measures could take place.
2546740	2549840	But that's the whole goal here. We want to make sure that it can't be done accidentally
2551540	2555540	or on purpose without it being obvious.
2559500	2563420	So the flight systems, the flight systems themselves, we've talked about these
2563420	2567960	quite a bit already. These need to be adversarially tested, of course. We need
2567960	2574600	to make sure that there's multiple levels of... there's multiple layers of protection
2574600	2579980	in the way for anybody who is trying to attack a system that they would need to get through.
2580260	2585180	No consumer interfaces. So all those flight systems, you need to make sure that you do not
2585180	2593840	have the... you don't have the... you know, there's no USB in there. There's no Wi-Fi in there.
2593840	2600580	So iPads as a flight bag are a thing now. And obviously, there's an appeal in terms of
2600580	2606380	how easy it is to update. You don't have to carry around stacks and stacks of paper.
2606860	2609360	There's... it's an easy way to store a lot of things.
2610960	2616260	But that means you've now got a device which is in the cockpit, which is considered a flight
2616260	2623400	critical system, which is a consumer device. And that gives me some concerns. So I think
2623400	2629640	there needs to be some thought on how to secure that type of system. Maybe it just needs to be
2629640	2633980	not an iPad. Maybe it can be a special purpose device. There's plenty of things out there with
2633980	2641980	LCD. They can store maps and have a program in them. No consumer interfaces. Yeah, so no USB.
2641980	2648240	You wouldn't be able to connect this. You don't want to have somebody accidentally plug in a USB
2648240	2665530	as you're not supposed to, right? So just as a quick summary here. Again, our goals.
2666450	2672710	These are the things that we want to achieve. And I think we have for what we've put
2672710	2678910	in place. Making sure we still have to assume, again, that's up front. An attacker has everything,
2678910	2685050	knows everything. We've talked about providing a way to make sure that the systems can be validated
2685050	2690350	to be correct. That the software and configurations on the different components are correct
2690350	2696510	when the aircraft, before the aircraft takes off. We want to limit that potential attack window.
2698730	2704670	We've talked about the ways we can prevent accidental transmission of something malicious
2704670	2713650	to the physical air gaps, physical disconnects, physical incompatible interfaces.
2714810	2718870	And then, again, if this is all, the goal is to make multiple barriers there.
2719650	2722950	Multiple barriers there an attacker would need to get through.
2727200	2732900	Yeah, and then two device categories. There's stuff that can affect flight and stuff that can't
2732900	2740160	affect flight. And can't affect flight does, in this case, mean physical, full physical isolation
2740160	2742180	of anything flight critical.
2746200	2752040	Methods. We've talked about these at length. Adversarial testing, I believe, is a big key part
2752040	2759080	of this. One thing I guess we didn't really talk about is kind of design standards. It's something
2759080	2765640	that could be addressed as well. Making sure that the software as it's developed complies with
2767020	2773640	the different best practice recommendation of how to develop secure software in terms of
2774340	2779780	functions that are allowed and such. That's another potential method. We are more looking
2779780	2788850	at the fitting things on top of what was there already. But we still do have a few problems
2788850	2794150	that we need to solve. We're not going to try and pretend that we solved everything here.
2794150	2799970	We'd like to think that we solved a significant part of aviation cybersecurity just in this talk.
2800830	2806810	But there's a few things that we need to think about going forward. Supply chain security is
2806810	2814010	still a concern. Obviously, as I said, anything can be hacked. As the devices are sitting in
2814010	2821290	storage, an attacker could go in and modify them. They've got plenty of time to go in and modify
2821290	2826670	them, figure out how they work. Either modify the software or just physically. Physical
2826670	2832610	modifications to the hardware. And how to make sure that that doesn't happen or can't happen
2833190	2844170	is a challenge. RF communication is also another area that we can't really address. The airplane
2844170	2853490	has a fair bit of RF communication. It has radio, ADS-B, weather, etc. This is also something that
2853490	2863250	wasn't addressed by what we've presented here in this talk. The flight crew, the pilot's training
2864120	2870090	is a significant part of that. If there's issues with communication between the aircraft and ground,
2870090	2876490	that's something where training can kick in and deal with the situation. But it is still
2876490	2882650	something that would improve matters if there was a way to secure the communications.
2885750	2890090	Things that we might also want to think about in the future are how often, how much change
2890090	2900070	would require something to be retested, more adversarial testing. What level of change,
2900070	2907870	where different amounts of change are considered to be minor fixes, and they don't have to require
2908130	2914150	a complete redesign of the system. But some level of change does require a complete redesign and
2914150	2919390	retesting the system. So that's something that would need to be looked at in the future.
2922200	2925840	And then there's also the maintenance devices themselves. We talked about how
2925840	2930240	maintenance devices are used to program all the different components on an aircraft.
2930240	2934920	This means that would be used to program both flight systems and these air-gapped non-flight
2934920	2941140	systems. So maybe those need to have a slightly different category. You could
2941140	2945560	argue, you can put together a committee meeting and argue about lots of this stuff for a while
2945560	2953260	if you want to. But I think that what we've given here is a fairly complete approach
2953260	2961020	to address cyber security. Any questions? We'll be in the discord for any questions.