1
00:00:04,970 --> 00:00:06,070
I'm Aaron Grelias.

2
00:00:06,070 --> 00:00:08,130
I'm a security researcher with Grimm.

3
00:00:08,130 --> 00:00:10,270
I'm on the cyber physical systems team.

4
00:00:10,270 --> 00:00:16,430
We work on improving the security of embedded devices everywhere.

5
00:00:16,430 --> 00:00:29,310
I've also got a background, a long background in embedded software development on critical systems, the telecom, aerospace, medical, and a bunch of different fields.

6
00:00:30,550 --> 00:00:32,030
My name is Tim Brown.

7
00:00:32,030 --> 00:00:35,050
I run the cyber physical systems team here at Grimm.

8
00:00:35,050 --> 00:00:45,230
I've been at Grimm for about five years now, hacking all sorts of different types of embedded systems from aerospace to automotive, heavy trucking, medical.

9
00:00:46,710 --> 00:00:52,510
And we're here today to talk about some of where cybersecurity meets aviation regulations.

10
00:01:05,510 --> 00:01:10,890
I'm going to start by talking about the current status of cybersecurity regulation.

11
00:01:10,890 --> 00:01:16,570
And more how software development happens in aerospace.

12
00:01:18,270 --> 00:01:28,110
The current process that we have descends from the, historically, how airlines have approached the topic of safety.

13
00:01:28,110 --> 00:01:35,530
Airlines have approached the topic of safety, usually, historically, from a purely mechanical standpoint.

14
00:01:35,530 --> 00:01:39,610
This part will last for about this long in airplanes.

15
00:01:39,610 --> 00:01:41,530
It has to be replaced every so often.

16
00:01:41,530 --> 00:01:49,810
There's maintenance procedures and airworthiness directives that talk about how often these parts need to be replaced based on how long it takes them to fail.

17
00:01:49,850 --> 00:02:07,070
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, if it's starting to get cracks forming in those areas.

18
00:02:07,230 --> 00:02:17,970
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.

19
00:02:17,970 --> 00:02:30,530
Once you design it, do all your fairly rigorous testing that they do in the airline, the aerospace industry, and install it, it will change in ways that are defined, essentially, by the physics of the situation.

20
00:02:30,530 --> 00:02:40,610
Stresses on metal, opening and closings of latches, and stuff like that, that have a defined physical characteristic.

21
00:02:40,610 --> 00:02:47,970
And you can define maintenance procedures that will detect all of these potential issues on the airplane.

22
00:02:47,970 --> 00:02:53,410
Maintenance procedures are defined to replace things that need to be replaced periodically.

23
00:02:53,410 --> 00:03:01,110
These maintenance procedures you can follow in the commercial aerospace world will be followed.

24
00:03:01,110 --> 00:03:04,650
They rely on that happening, that does happen.

25
00:03:05,150 --> 00:03:07,910
And they do it in places like this.

26
00:03:07,910 --> 00:03:15,290
They have drawers that have labeled places for every bit, every socket, every tool.

27
00:03:15,290 --> 00:03:16,890
It's access controlled.

28
00:03:16,890 --> 00:03:25,810
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.

29
00:03:25,810 --> 00:03:29,050
So you don't wind up leaving a socket in an airplane.

30
00:03:29,050 --> 00:03:38,830
They have these fairly strictly defined procedures that you follow in order to make sure that all these maintenance is done correctly and done completely.

31
00:03:42,510 --> 00:03:47,190
So that's the kind of history of where we came from.

32
00:03:47,190 --> 00:04:02,970
As far as the current regulations that drive the software development process for modern aviation software, that's regulated at least in this country and many other ones by something called DO-178C.

33
00:04:03,230 --> 00:04:17,350
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 how to go forward with that.

34
00:04:17,730 --> 00:04:20,410
This is developed by RTCA.

35
00:04:20,430 --> 00:04:27,530
It stands for Radio Technical Commissions for Aeronautics, which I never actually knew until I looked that up.

36
00:04:27,530 --> 00:04:28,690
It's not super important.

37
00:04:28,690 --> 00:04:31,850
It's just an organization that develops a bunch of aviation standards.

38
00:04:34,350 --> 00:04:43,870
And again, these are adopted by FAA in the United States, Transport Canada, and European Aviation Safety Agency, EASA.

39
00:04:45,490 --> 00:04:47,550
So what is DO-178C?

40
00:04:47,550 --> 00:04:49,510
I like to summarize it this way.

41
00:04:49,570 --> 00:04:58,490
You basically tell the FAA... well, a DER is the designated representative that stands in for the FAA.

42
00:04:58,490 --> 00:05:03,990
Tell them how you plan on designing, creating, and testing your software.

43
00:05:04,310 --> 00:05:07,750
And then you go and follow your plan and do those things.

44
00:05:07,750 --> 00:05:09,870
And then you have to prove that you followed your plan.

45
00:05:09,870 --> 00:05:11,750
That's it in a nutshell.

46
00:05:11,990 --> 00:05:15,150
Now there's a lot more paperwork involved.

47
00:05:15,150 --> 00:05:23,970
There's a lot of checklists you do have to go through and make sure that your plan actually does identify all the areas of concern that DO-178C points out.

48
00:05:24,290 --> 00:05:35,850
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.

49
00:05:36,010 --> 00:05:39,170
That's the way things go forward right now.

50
00:05:39,170 --> 00:06:06,090
And as you can see, it's kind of a very waterfall-y based model where you do all your design up front, you create a design, you create a spec, the actual product that implements the design, then you do testing on it in order to make sure that the product design actually meets the requirements that the product was supposed to fulfill.

51
00:06:06,350 --> 00:06:07,730
That is a good point.

52
00:06:07,730 --> 00:06:11,990
The way this does work in practice, it is extremely waterfall.

53
00:06:13,370 --> 00:06:20,930
There have been attempts to try and figure out how to fit Agile methods into this, but it is very much plan, do, prove.

54
00:06:21,170 --> 00:06:23,210
Just pretty much in those steps.

55
00:06:23,450 --> 00:06:30,930
And this again comes from that historical background of making mostly mechanical components where that is how you design them.

56
00:06:30,930 --> 00:06:37,670
You don't do iterative development on, you know, a weight usually.

57
00:06:37,670 --> 00:06:45,510
I mean, if there's issues, you'll go back and fix them of course, but like you don't really do, you know, there is no fail fast on making a lot of these mechanical components.

58
00:06:45,510 --> 00:06:54,150
So it's trying to shoehorn software development into how they make mechanical components for these aircraft.

59
00:06:54,370 --> 00:07:02,070
And as anybody who's been in software development for a while knows that waterfall has been around for a long time.

60
00:07:02,870 --> 00:07:12,230
The DO-178C categorizes different levels of software according to the potential consequences of a failure of that software.

61
00:07:13,090 --> 00:07:21,890
So levels A through E, and basically A means that something catastrophic would happen if it fails.

62
00:07:22,270 --> 00:07:30,370
Level E means that nothing is going to happen safety wise, you know, maybe the passengers can't watch movies, right?

63
00:07:30,370 --> 00:07:32,790
That would be a level E software.

64
00:07:33,530 --> 00:07:36,610
The level A is also the highest cost.

65
00:07:36,610 --> 00:07:37,950
This is probably unsurprising.

66
00:07:41,230 --> 00:07:49,630
The last numbers I can find show that it's estimated to be about $100 per line of code for level A software.

67
00:07:51,050 --> 00:07:54,530
They're not all software on an airplane is level A.

68
00:07:54,530 --> 00:07:58,430
It's usually just as small percentage as possible because of the cost.

69
00:07:58,830 --> 00:08:04,530
But Boeing 787, for example, is estimated to have between 6 and 7 million lines of code.

70
00:08:04,530 --> 00:08:12,610
So even if it's a small percentage, just the level of certification alone of the software drives a great deal of cost.

71
00:08:13,470 --> 00:08:16,030
Basically, these go from different levels.

72
00:08:16,150 --> 00:08:32,430
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.

73
00:08:32,430 --> 00:08:34,170
Then they go on both.

74
00:08:34,170 --> 00:08:43,570
Level B would be something where something hazardous could happen, but also level B will typically allow for pilot intervention.

75
00:08:43,890 --> 00:08:56,250
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 training.

76
00:08:56,250 --> 00:08:59,430
Level A and B is usually loss of life.

77
00:08:59,430 --> 00:09:03,830
A level A failure was likely to lead to loss of life.

78
00:09:03,830 --> 00:09:10,450
Level B failure is not likely to lead to loss of life or severe injury.

79
00:09:11,030 --> 00:09:15,330
Injury sustained in a level B failure should be minimal.

80
00:09:17,130 --> 00:09:19,330
And then it goes on down from there.

81
00:09:19,330 --> 00:09:24,390
C and D are major minor impacts to the flight of the aircraft.

82
00:09:27,750 --> 00:09:37,810
Also, so entertainment systems are going to be level E, means that there's lower, less regulations and less checklists, essentially.

83
00:09:37,810 --> 00:09:43,630
As you go down in level, you have to do less to prove in that proof step.

84
00:09:47,100 --> 00:09:51,920
In DO-178C, code is expensive.

85
00:09:51,920 --> 00:10:02,760
So stuff, especially if it's a level B or level A, very unlikely to have unused code in it or unnecessary code in it, like a shell onto a system .

86
00:10:04,860 --> 00:10:15,380
DO-178A, you're not allowed to have dead code in your design on the system.

87
00:10:16,600 --> 00:10:23,480
Because it's so expensive to develop the code, there's usually a minimal amount of code on these systems.

88
00:10:23,480 --> 00:10:28,640
There is extensive testing done for the higher certification levels.

89
00:10:28,640 --> 00:10:32,060
There's at least a significant quantity of testing done.

90
00:10:33,000 --> 00:10:40,400
Pilot training on how to use the software is... the systems are designed for redundancy and safety.

91
00:10:40,400 --> 00:10:46,880
So if you do have a failure, there should be a redundant system to back up that failure.

92
00:10:46,880 --> 00:10:50,620
Unless you have a 737 MAX, we won't talk about that right now.

93
00:10:51,480 --> 00:10:56,120
Very limited interfaces on these flight-critical systems.

94
00:10:56,220 --> 00:10:58,240
They use interfaces like RN429.

95
00:10:58,240 --> 00:11:01,180
RN429 is a UART-style bus.

96
00:11:01,180 --> 00:11:07,560
You're limited to sending 32 bits of data at a time.

97
00:11:07,560 --> 00:11:10,060
There's not really room for buffer overflow here.

98
00:11:10,060 --> 00:11:14,100
You don't really have longer messages on top of RN429.

99
00:11:14,500 --> 00:11:25,180
These interfaces are very strictly defined and fairly provide very limited functionality beyond just sending the necessary critical data back and forth on the bus.

100
00:11:25,180 --> 00:11:29,320
There's a great deal of emphasis on determinism and reliability.

101
00:11:34,300 --> 00:11:46,180
So there's some bad things related to the current way software is defined and designed in aerospace.

102
00:11:47,160 --> 00:11:59,240
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.

103
00:11:59,760 --> 00:12:06,920
The things that... I found many things frustrating when I was doing on the development side of things.

104
00:12:06,920 --> 00:12:11,480
This is kind of the... a piece of that list right here.

105
00:12:11,500 --> 00:12:17,440
Data validation is guarding against accidental data modification.

106
00:12:17,440 --> 00:12:28,720
The design of how software is made to be robust in aviation systems is guarding against like cosmic rate bit flips, single event upsets.

107
00:12:28,720 --> 00:12:34,040
So simple methods like CRCs and checksums are sufficient.

108
00:12:34,040 --> 00:12:49,180
And also the software that runs it is typically slower and older, more reliable, and therefore modern data validation methods are... can be very time consuming for those... for the hardware involved.

109
00:12:49,280 --> 00:12:52,320
There's very little code to guard against unexpected scenarios.

110
00:12:52,320 --> 00:13:11,630
If you don't... if it's... if every single line of code costs a hundred dollars approximately, probably more nowadays than it was when I found that statistic, then you're not going to have a code for guarding against things that the system designers say won't happen.

111
00:13:11,630 --> 00:13:18,790
In fact, as Tim says, dead code, code that is never expected to be executed, is not allowed in DO-178C.

112
00:13:20,470 --> 00:13:22,410
The... there's a lot of complacency.

113
00:13:22,410 --> 00:13:39,470
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 into the system, protect us from bad things.

114
00:13:39,630 --> 00:13:42,150
And it protects against single event upsets.

115
00:13:42,150 --> 00:13:47,570
It doesn't protect against determined and directed attacks.

116
00:13:48,190 --> 00:13:58,130
One thing... one piece of software I was working on a while ago had a... just a straight-up buffer overflow attack against it.

117
00:13:58,150 --> 00:14:14,930
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.

118
00:14:14,990 --> 00:14:29,390
And if there was some sort of, like Aaron says, a single event upset, a sort of random bit flip that caused the length field to be longer than it was supposed to be, there's a CRC check that would have failed, and wouldn't have even processed the data at all.

119
00:14:29,390 --> 00:14:42,830
So 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.

120
00:14:42,830 --> 00:14:53,510
They believe that the only way for data to get into this function is from a source that they trust to not send data that's going to cause a buffer overflow.

121
00:14:54,530 --> 00:14:56,590
So Tim's kind of jumping ahead there.

122
00:14:56,590 --> 00:15:02,130
That last bullet point on this one is software is only tested against expected flight configurations.

123
00:15:02,370 --> 00:15:10,590
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.

124
00:15:10,590 --> 00:15:15,090
There's a lot of tests that are performed as part of this software certification process.

125
00:15:15,090 --> 00:15:17,410
You don't want to run more than necessary.

126
00:15:17,570 --> 00:15:33,510
What that means, though, is that software, aviation software, while robust in flight configurations, can be extremely brittle when it is put into conditions that it is not, that are not expected to happen.

127
00:15:34,410 --> 00:15:46,110
Some other things here, ground maintenance devices, so things that actually program the different flight devices, those are not D1C rated, because they're not flying, right?

128
00:15:46,110 --> 00:15:48,690
They just stay on the ground while the airplane flies.

129
00:15:48,730 --> 00:15:58,010
They're covered under some different guidelines about tool development, but you don't have to go, they're not even leveling certified, it's something different.

130
00:15:59,650 --> 00:16:06,350
Maintenance software, so on each box, there's typically a component that will help reprogram that device.

131
00:16:06,990 --> 00:16:16,450
That's considered to be deactivated, because when the airplane is in flight, you have a signal that says, are we, are the wheels on the ground or not?

132
00:16:16,450 --> 00:16:19,530
Sometimes it's called weight on wheels, sometimes it's called weight off wheels.

133
00:16:19,530 --> 00:16:22,070
Make sure you read your documentation very carefully.

134
00:16:23,430 --> 00:16:37,890
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.

135
00:16:37,930 --> 00:16:40,590
So this is considered to be deactivated.

136
00:16:40,970 --> 00:16:49,410
There's also frequently a physical switch on the piece of hardware they have to switch into some sort of boot mode, maintenance mode, programming mode.

137
00:16:49,410 --> 00:17:02,810
So you have to not only have the weight on wheels signal, but you also have to have this switch set in the activated position to boot the piece of hardware into the maintenance mode.

138
00:17:02,810 --> 00:17:08,830
And then the plane won't fly if that piece of hardware is in its maintenance mode or programming mode.

139
00:17:08,830 --> 00:17:12,770
You have to switch it back to flight mode before the plane will take off.

140
00:17:12,770 --> 00:17:18,010
Right, and it'll be like programmed sometimes that are built into the wiring harnesses themselves.

141
00:17:18,010 --> 00:17:25,670
So when you plug in the harness for reprogramming a box, that thing has a wire jumper in it that forces this type of mode.

142
00:17:30,090 --> 00:17:36,830
So there are some current cybersecurity documents out there, DO-326, which

143
00:17:41,550 --> 00:17:43,270
DO -326,

144
00:17:48,290 --> 00:17:54,190
which outlines the activities that should take place at a system and airframe levels.

145
00:17:54,190 --> 00:18:03,130
These are the type of security activities that you should do if you're developing either a system for an airplane or developing the entire airplane.

146
00:18:03,290 --> 00:18:10,330
These are the various testing activities and testing documents that you should create and how to create them.

147
00:18:10,610 --> 00:18:16,570
DO-356 goes a little bit more into the nuts and bolts of what testing should look like.

148
00:18:16,890 --> 00:18:27,090
Something I like about DO-356 is DO-356 does make provisions for the more ad hoc pentest style testing that hackers tend to do.

149
00:18:27,090 --> 00:18:39,090
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 that you can then exploit into the system.

150
00:18:39,090 --> 00:18:47,470
This is a testing that's much... most testing that you see, especially the DO-178C type testing, is extremely formalized.

151
00:18:47,470 --> 00:18:49,670
Every test procedure is written down.

152
00:18:49,670 --> 00:18:51,190
You do this set of procedures.

153
00:18:51,190 --> 00:18:52,390
This is your test.

154
00:18:52,390 --> 00:18:55,090
That's going to... there's conditions to pass.

155
00:18:55,350 --> 00:18:59,230
There's conditions for... and if they don't meet the passing conditions, the test failed.

156
00:19:00,030 --> 00:19:07,710
DO-356 does provide those provisions for the more ad hoc style testing that can be much more useful for security testing.

157
00:19:07,710 --> 00:19:16,310
Provisions for things like fuzzing, which doesn't really have an analog in like DO-178C, but you can't really formalize a fuzzing procedure.

158
00:19:18,690 --> 00:19:21,730
So that's where we are right now.

159
00:19:22,070 --> 00:19:29,050
We've got some concerns with the current way aviation software is currently defined.

160
00:19:29,070 --> 00:19:30,490
What do we do?

161
00:19:30,570 --> 00:19:32,150
So what do we do about that?

162
00:19:32,150 --> 00:19:34,410
Well, Tim and I have a plan.

163
00:19:36,670 --> 00:19:51,370
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.

164
00:19:51,370 --> 00:20:05,030
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.

165
00:20:08,320 --> 00:20:13,700
So the problem is up front here, everything is hackable, right?

166
00:20:13,780 --> 00:20:17,400
Give some... give enough access, motivation, time, and money.

167
00:20:17,400 --> 00:20:19,940
You can get into any type of device.

168
00:20:19,940 --> 00:20:23,560
You give us a piece of hardware, and we can get into it.

169
00:20:24,840 --> 00:20:36,240
There's a lot of measures you can use to make it more difficult, but depend... with a large enough playground, you can get into anything you want.

170
00:20:42,270 --> 00:20:53,390
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.

171
00:20:53,470 --> 00:21:04,430
If we're going to... if 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.

172
00:21:04,990 --> 00:21:18,230
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 a particular component is 100% correct.

173
00:21:18,230 --> 00:21:26,210
If you cannot prove that, then it's going to be impossible to figure out how to get to secure an aircraft.

174
00:21:28,230 --> 00:21:32,810
We need to prevent accidental transmission of something malicious.

175
00:21:32,810 --> 00:21:42,250
If you know that everything is secure at some point in time, you need to, you know, protect it from going forward, and then put multiple barriers in place also to all these different components.

176
00:21:42,970 --> 00:21:49,850
We know that given enough time and money and so on, anybody can get into a device if they want to.

177
00:21:49,850 --> 00:22:00,830
But it is possible to figure out how to prevent, make an attack practically impossible if you limit some of those things.

178
00:22:00,830 --> 00:22:17,630
So if you know when an airplane is on the ground, that it has all of the correct software and configurations in all of 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.

179
00:22:17,630 --> 00:22:20,350
So that's what we're aiming for.

180
00:22:20,650 --> 00:22:34,970
And also aiming to get the idea into aviation that a software component can go from good to bad very quickly.

181
00:22:35,010 --> 00:22:42,890
Just one exploit and all of a sudden this device that was working completely fine is now no longer working completely fine.

182
00:22:42,890 --> 00:22:48,730
And it's not based on some statistical degradation over time.

183
00:22:48,730 --> 00:22:51,510
Now that can just go be good and then be bad.

184
00:22:55,910 --> 00:23:01,150
So to define what is important to secure, here's my list.

185
00:23:01,170 --> 00:23:04,450
We have things that are important for flying an aircraft.

186
00:23:04,550 --> 00:23:07,890
And then we have things that are not important for flying the aircraft.

187
00:23:07,890 --> 00:23:10,870
These are two device categories.

188
00:23:11,330 --> 00:23:25,370
The level D-178C defines five different levels to how critical software is and the consequences of failures here.

189
00:23:25,530 --> 00:23:30,090
For us, there's really only two categories, important or not.

190
00:23:30,110 --> 00:23:41,250
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.

191
00:23:48,730 --> 00:23:54,570
So flight devices are any component that's used to operate the aircraft.

192
00:23:55,310 --> 00:23:58,470
Any or any device that communicates with those components.

193
00:23:58,470 --> 00:24:09,730
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.

194
00:24:09,910 --> 00:24:31,070
And this is allowed because that communication has been strictly defined and tested on the piece of hardware, the level A software, to make sure that it should reject any bad inputs with oftentimes not very robust checking on what these bad inputs actually are.

195
00:24:31,530 --> 00:24:39,790
But from a security context, anywhere that you can touch something important from, also needs to be secured.

196
00:24:39,950 --> 00:24:54,990
Because if you can, you know, have a lower functional, lower functioning device, lower classification, lower DO1s, then you see a DAL classification device that can maybe in some way disrupt a higher level, more critical device.

197
00:24:54,990 --> 00:25:04,230
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 onto a more critical system.

198
00:25:05,950 --> 00:25:18,270
And also any device or software that interacts with these components, whether in the flight or on the ground, all your ground maintenance software, is now needs to be considered essentially from a security level, the same as a flight device.

199
00:25:18,270 --> 00:25:30,210
Because these are things that are designed to be able to modify the behavior of these pieces of hardware that are responsible for directly controlling the flight of the aircraft.

200
00:25:30,670 --> 00:25:35,330
I think that's an important point of what we're defining here.

201
00:25:35,330 --> 00:25:42,190
Things that we consider flight devices includes the things on the ground that program the device.

202
00:25:42,250 --> 00:25:52,450
Because those are very critical to making sure that the correct and only the correct components are programmed.

203
00:25:53,690 --> 00:26:02,550
You know, one thing also, Tim talked about the different components, different level of components talking together on the same bus.

204
00:26:02,550 --> 00:26:12,750
One very common level A software item on recent aircraft is an operating system running on a particular device.

205
00:26:12,750 --> 00:26:30,530
There is a standard called RX-653, which defines ways for a partitioned operating system that's effectively like a virtual machine, can have multiple different severity levels running on the same component.

206
00:26:31,250 --> 00:26:37,050
So as we all know, in security though, virtual machine escapes are definitely a thing.

207
00:26:37,130 --> 00:26:49,550
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 there, pivot into the operating system itself, or a more critical component if they wanted to.

208
00:26:53,980 --> 00:26:55,580
So that's our devices.

209
00:26:56,240 --> 00:26:58,220
How do we go about doing this?

210
00:26:58,220 --> 00:27:00,600
Well, we've got a couple different things here.

211
00:27:02,800 --> 00:27:05,780
So there's adversarial testing.

212
00:27:07,060 --> 00:27:12,660
I choose the word adversarial testing because I don't want to say pentesting, because pentesting means different things to different people.

213
00:27:12,660 --> 00:27:19,500
This is the idea of testing the system as an attacker would.

214
00:27:19,500 --> 00:27:24,940
You're no longer just strictly checking against a specification.

215
00:27:25,040 --> 00:27:30,140
You're actually looking at it from, if I'm an attacker, how could I leverage this system to do something?

216
00:27:30,140 --> 00:27:33,400
How could I use this protocol to do something?

217
00:27:33,400 --> 00:27:41,600
All the things that, you know, security professionals that we do in our jobs, how do we, you know, doing these things to now an airplane?

218
00:27:43,180 --> 00:27:48,120
Another method is some sort of pre-flight software and configuration authentication.

219
00:27:48,840 --> 00:28:03,540
If before every 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 a cryptographically secure method of validating that the software that's running is the software that's supposed to be running,

220
00:28:03,540 --> 00:28:06,060
that your configuration is correct.

221
00:28:07,680 --> 00:28:28,320
Other methods could include like 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, you know, they don't speak these commodity protocols like USB or Bluetooth or Wi-Fi.

222
00:28:28,320 --> 00:28:29,960
We'll talk about this a little bit later.

223
00:28:30,960 --> 00:28:33,940
We also need to talk about air gaps.

224
00:28:33,940 --> 00:28:54,620
I know anybody in ICS 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,

225
00:28:54,620 --> 00:28:57,740
at least as a passenger sitting in the plane.

226
00:29:00,480 --> 00:29:05,400
Now the adversarial testing, you know, review and test all interfaces for vulnerabilities.

227
00:29:05,400 --> 00:29:22,900
You know, you have to, you can't trust, just blindly trust the external inputs into the system, even if they should only be coming from a system that's also been tested in the same level and should only be producing correct outputs for you to consume,

228
00:29:22,900 --> 00:29:29,060
you still can't trust this because you can't always trust that the system hasn't been compromised in some way.

229
00:29:29,500 --> 00:29:34,780
I'd like to give an example from automotive for that.

230
00:29:34,780 --> 00:29:50,860
If you have one component that tells you the brake is pressed and you make sure that the thing that actually generates the signal saying the brake is pressed works perfectly, can't be cracked, the thing that interprets that signal works perfectly, can't be cracked,

231
00:29:50,860 --> 00:30:01,480
it's all well and good, but if you then have an entertainment system on the same bus and that sends a message saying the brake is pressed, well, now you can't trust your inputs, can you?

232
00:30:04,400 --> 00:30:07,620
Yeah, and testing your protocol stacks and milestones for vulnerability.

233
00:30:07,640 --> 00:30:17,520
I mean, we've gotten a little bit better, but there's been lots of vulnerabilities found in TCP IP stacks and other network stacks over the years.

234
00:30:18,300 --> 00:30:28,300
Reviewing the software and compile code for vulnerabilities, making sure you're doing static analysis on the code, not a perfect solution, but it does catch some things.

235
00:30:29,440 --> 00:30:37,800
Secure boot is, I think, a fairly critical part of making sure that we can actually trust the software running on the systems.

236
00:30:37,800 --> 00:30:55,700
Having a good, secure boot platform set up could go a very long way to preventing at least an attacker from modifying the operating system that should then be modifying the software that runs on this platform because it should be detected.

237
00:30:56,320 --> 00:30:59,120
And , of course, having multiple layers of protection.

238
00:30:59,620 --> 00:31:07,520
Defense in depth has always been one of the strongest things you can do for the security posture of basically anything.

239
00:31:09,120 --> 00:31:17,220
The topic of secure boot is one that could be talked about for a long time and different people have different definitions of what secure boot means.

240
00:31:18,460 --> 00:31:36,960
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 authorized software and components are installed and operating on that device.

241
00:31:37,000 --> 00:31:44,060
And a way to store the keys that should be immutable.

242
00:31:45,220 --> 00:31:45,860
Right.

243
00:31:45,860 --> 00:32:01,860
And also, 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 of the devices.

244
00:32:01,940 --> 00:32:02,200
Right.

245
00:32:02,200 --> 00:32:10,280
Something that is, uses perhaps asymmetric cryptography methods and secure hashing to be used for device.

246
00:32:13,720 --> 00:32:17,980
So pre-flight software authentication, talked about this a little bit earlier.

247
00:32:17,980 --> 00:32:26,160
We want to make sure that the before takeoff that everything on the aircraft is 100% correct and secure and authentic.

248
00:32:27,880 --> 00:32:36,140
So this would be some way, some centralized way to query every single device and find out what software and configuration are running on them.

249
00:32:36,140 --> 00:32:46,160
This is already somewhat in existing, you know, before an aircraft flies, this is already somewhat what happens, right?

250
00:32:46,160 --> 00:32:50,120
We need to make sure that only the correct software is on each component.

251
00:32:50,120 --> 00:32:58,980
So people who fly aircraft will already have a list of different software versions that should be running on each component of the aircraft.

252
00:32:58,980 --> 00:33:03,320
So this isn't as outlandish as it sounds.

253
00:33:04,260 --> 00:33:07,940
You can use cryptographic and secure algorithms, no CRCs, no checksums.

254
00:33:07,940 --> 00:33:13,680
You should be using something like SHA-2, SHA-3, something better.

255
00:33:14,100 --> 00:33:22,800
And there should be also the protocol, the way the centralized device queries every single component, there should be a challenge response protocol here.

256
00:33:22,800 --> 00:33:29,160
The protocol should also be tested adversarially to make sure there is something that cannot be spoofed.

257
00:33:29,160 --> 00:33:31,520
We need to make sure we can prevent replay attacks.

258
00:33:31,520 --> 00:33:43,260
So if there is some malicious software, malicious component on a box, it should be incapable of falsifying the authenticity of that software.

259
00:33:43,260 --> 00:33:48,620
You can also validate the entire range of memory and flash on each device.

260
00:33:48,940 --> 00:33:52,680
You want to make sure that you can't set the length to zero.

261
00:33:52,680 --> 00:34:05,300
You want to make sure that you don't have the correct software and the correct configuration and put some sort of mystery component in the middle and that that gap just isn't checked because it wasn't thought to be important, right?

262
00:34:05,300 --> 00:34:07,900
You need to make sure that the entire range is validated.

263
00:34:14,800 --> 00:34:27,280
Yeah, physically incompatible interfaces, you know, we're seeing that like the flight crews, they have the iPad devices that will be there, their flight book that has the flight information.

264
00:34:27,900 --> 00:34:43,700
One of the ways to make sure to, one order to help prevent malicious software from being loaded onto these flight critical systems is to make sure that there are physically incompatible interfaces between the non-flight systems and the flight capable systems.

265
00:34:43,700 --> 00:34:59,180
So your flight cable systems shouldn't have USB, they shouldn't have Bluetooth, they shouldn't have Wi-Fi, they shouldn't have these standardized protocols that everything speaks, you know, specialized hardwired connections like the connections we have a picture of here,

266
00:34:59,180 --> 00:35:07,280
very common in aerospace, just make it a lot harder for the flight crew to just plug their iPad into a flight critical system.

267
00:35:08,240 --> 00:35:14,800
And if you can see on these connectors, some of the important parts of them is that they've actually got different keying.

268
00:35:14,800 --> 00:35:23,000
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.

269
00:35:23,000 --> 00:35:26,800
But then you, there's a lot of different varieties of keying.

270
00:35:26,800 --> 00:35:30,460
Some have five slots, some have four, different widths, different positions.

271
00:35:30,600 --> 00:35:35,820
And the whole idea is that you want to make sure that you cannot connect a component wrong.

272
00:35:35,820 --> 00:35:39,460
This is already what's done on an aircraft for connecting all the different flight components.

273
00:35:39,460 --> 00:35:45,940
And this is something that we say is necessary when connecting anything to a flight system.

274
00:35:50,040 --> 00:35:56,920
So air gaps, as Tim said, everybody who's in ICS is probably laughing when we had that out there before.

275
00:35:56,920 --> 00:36:00,160
But the whole point is that an aircraft doesn't change.

276
00:36:00,340 --> 00:36:04,460
If it changes, it changes because the design of the aircraft changes.

277
00:36:04,460 --> 00:36:10,740
It changes because there was an actual documented and, you know, tested reason for doing so.

278
00:36:11,100 --> 00:36:20,300
So designing the system, you should make sure that the flight systems and the non-flight systems cannot talk at all.

279
00:36:22,280 --> 00:36:24,400
They should be physically separate.

280
00:36:25,020 --> 00:36:27,900
We, as I said, virtual machine escapes are definitely a thing.

281
00:36:27,900 --> 00:36:29,500
You should not be running on the same box.

282
00:36:29,500 --> 00:36:32,020
They should not be able to even talk on the same bus.

283
00:36:33,300 --> 00:36:39,420
So anything that needs, if somebody, you don't want to have to test everything on an aircraft, right?

284
00:36:39,420 --> 00:36:49,160
You want to make sure you can, you want to try and trim what you need to test because testing is expensive.

285
00:36:49,440 --> 00:36:54,980
So something like an entertainment system, maybe somebody doesn't want to go about testing that.

286
00:36:54,980 --> 00:36:56,040
Well, that's okay.

287
00:36:56,520 --> 00:37:04,560
If you can make sure that that entertainment system can never ever talk to a flight system, which means no common buses.

288
00:37:04,600 --> 00:37:13,520
It means that the only thing on the aircraft connected to that entertainment system from the flight components is power.

289
00:37:13,840 --> 00:37:25,620
If you need somebody to, if the 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.

290
00:37:33,550 --> 00:37:38,090
So some examples of what we've got here.

291
00:37:38,090 --> 00:37:46,690
We're going to go through some different categories, three different types of systems and talk about how we would apply these things to ensure that they're secure.

292
00:37:48,130 --> 00:37:49,030
Maintenance.

293
00:37:49,030 --> 00:37:56,190
In these cover, this is pretty much the, you know, all the different types of devices that you would have on an aircraft, right?

294
00:37:56,190 --> 00:38:01,630
Passenger accessible systems, things that passengers can get access to and so on.

295
00:38:04,980 --> 00:38:07,120
So maintenance devices.

296
00:38:07,520 --> 00:38:11,740
These are the things that program the different components when the aircraft is on the ground.

297
00:38:12,540 --> 00:38:24,060
They're 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.

298
00:38:25,720 --> 00:38:29,460
These need to be adversarially tested.

299
00:38:29,460 --> 00:38:32,980
This is, should be unsurprising to hear by now.

300
00:38:33,280 --> 00:38:46,300
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.

301
00:38:46,420 --> 00:38:52,880
As I said, they're typically a regular laptop or some sort of PC type device.

302
00:38:52,880 --> 00:39:03,320
So any of the standard ways to secure a PC, you know, a laptop should be used on these devices to make auditing.

303
00:39:03,440 --> 00:39:10,560
They should have auditing on, they should have all the different security protections in place.

304
00:39:11,420 --> 00:39:18,600
Programming other devices as well, as typically it can happen to, there is an ERIN standard for this as well, although it's optional.

305
00:39:18,600 --> 00:39:20,300
Not every device implements it.

306
00:39:20,300 --> 00:39:29,360
It's called ERIN 615 for data loading and that can happen over multiple types of device buses such as ERIN 429.

307
00:39:30,140 --> 00:39:33,320
These devices will then usually talk over that.

308
00:39:33,320 --> 00:39:34,780
It's kind of a double-edged sword.

309
00:39:34,780 --> 00:39:38,400
On one hand, it means you've got a standard way of doing things.

310
00:39:38,400 --> 00:39:55,760
On the other hand, it means that if somebody implements ERIN 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 back and forth challenge response authentication on both ends.

311
00:39:55,940 --> 00:40:02,620
The device should make sure that the device programming it is who it says it is and vice versa.

312
00:40:03,380 --> 00:40:06,180
Full mutual authentication.

313
00:40:06,180 --> 00:40:07,800
That's the term.

314
00:40:11,040 --> 00:40:33,100
So passenger accessible systems should either be incapable of connecting to aircraft systems, not physically connected in any way, not physically sharing any piece of hardware, ideally not even speaking the same sort of protocols so they couldn't even accidentally be connected together.

315
00:40:33,100 --> 00:40:37,360
You can't just plug USB into ERIN 429 and have it work.

316
00:40:37,980 --> 00:40:50,300
Or they need to be same as everything else adversarial tested and not have external connectivity that a normal passenger would be able to just plug into and use.

317
00:40:50,420 --> 00:40:54,420
If you have a USB for charging, it should only be for charging.

318
00:40:54,420 --> 00:40:55,820
Only the data lines should be connected.

319
00:40:55,820 --> 00:41:02,500
It shouldn't have any of the... you should be capable of passing data back and forth.

320
00:41:05,320 --> 00:41:21,660
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.

321
00:41:21,660 --> 00:41:22,480
Yes.

322
00:41:22,740 --> 00:41:26,960
But that's the only case where that would be allowed.

323
00:41:26,960 --> 00:41:30,220
You would need to make sure that this device cannot talk to anything else.

324
00:41:30,220 --> 00:41:50,200
And the whole goal here is to make sure that something can't be done, something cannot accidentally or through somebody dropping a bad cable somewhere near the airport, have somebody connect something that shouldn't be connected to the flight systems.

325
00:41:50,200 --> 00:41:51,280
That's the whole goal here.

326
00:41:51,280 --> 00:42:07,200
If somebody is going to try and attack an aircraft during that 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.

327
00:42:07,360 --> 00:42:11,020
So just plugging the USB in is very benign.

328
00:42:11,100 --> 00:42:25,320
But if they're starting to rip up panels and trying to find the 429 bus somewhere down there, well, that should hopefully be obvious to some of the other passengers or the crew and corrective measures could take place.

329
00:42:26,740 --> 00:42:28,120
But that's the whole goal here.

330
00:42:28,120 --> 00:42:35,540
We want to make sure that it can't be done accidentally or on purpose without it being obvious.

331
00:42:39,500 --> 00:42:45,360
So the flight systems, the flight systems themselves, we've talked about these quite a bit already.

332
00:42:45,460 --> 00:42:47,760
These need to be adversarially tested, of course.

333
00:42:47,760 --> 00:42:59,980
We need to make sure that there's multiple levels of... there's multiple layers of protection in the way for anybody who is trying to attack a system that they would need to get through.

334
00:43:00,260 --> 00:43:01,920
No consumer interfaces.

335
00:43:02,200 --> 00:43:12,160
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.

336
00:43:12,160 --> 00:43:13,840
There's no Wi-Fi in there.

337
00:43:13,840 --> 00:43:16,920
So iPads as a flight bag are a thing now.

338
00:43:17,580 --> 00:43:22,360
And obviously, there's an appeal in terms of how easy it is to update.

339
00:43:22,520 --> 00:43:26,380
You don't have to carry around stacks and stacks of paper.

340
00:43:26,860 --> 00:43:29,360
There's... it's an easy way to store a lot of things.

341
00:43:30,960 --> 00:43:38,780
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.

342
00:43:39,460 --> 00:43:42,740
And that gives me some concerns.

343
00:43:42,740 --> 00:43:48,320
So I think there needs to be some thought on how to secure that type of system.

344
00:43:48,440 --> 00:43:50,960
Maybe it just needs to be not an iPad.

345
00:43:50,960 --> 00:43:52,840
Maybe it can be a special purpose device.

346
00:43:52,840 --> 00:43:54,880
There's plenty of things out there with LCD.

347
00:43:54,880 --> 00:43:57,520
They can store maps and have a program in them.

348
00:43:59,320 --> 00:44:00,700
No consumer interfaces.

349
00:44:00,700 --> 00:44:01,980
Yeah, so no USB.

350
00:44:01,980 --> 00:44:03,840
You wouldn't be able to connect this.

351
00:44:04,780 --> 00:44:09,980
You don't want to have somebody accidentally plug in a USB as you're not supposed to, right?

352
00:44:16,170 --> 00:44:20,970
So just as a quick summary here.

353
00:44:23,550 --> 00:44:25,530
Again, our goals.

354
00:44:26,450 --> 00:44:30,710
These are the things that we want to achieve.

355
00:44:30,770 --> 00:44:33,710
And I think we have for what we've put in place.

356
00:44:34,150 --> 00:44:37,850
Making sure we still have to assume, again, that's up front.

357
00:44:37,850 --> 00:44:40,090
An attacker has everything, knows everything.

358
00:44:41,130 --> 00:44:46,310
We've talked about providing a way to make sure that the systems can be validated to be correct.

359
00:44:47,330 --> 00:44:53,430
That the software and configurations on the different components are correct when the aircraft, before the aircraft takes off.

360
00:44:53,430 --> 00:44:56,510
We want to limit that potential attack window.

361
00:44:58,730 --> 00:45:13,650
We've talked about the ways we can prevent accidental transmission of something malicious to the physical air gaps, physical disconnects, physical incompatible interfaces.

362
00:45:14,810 --> 00:45:18,870
And then, again, if this is all, the goal is to make multiple barriers there.

363
00:45:19,650 --> 00:45:22,950
Multiple barriers there an attacker would need to get through.

364
00:45:27,200 --> 00:45:30,460
Yeah, and then two device categories.

365
00:45:30,460 --> 00:45:33,900
There's stuff that can affect flight and stuff that can't affect flight.

366
00:45:34,800 --> 00:45:42,180
And can't affect flight does, in this case, mean physical, full physical isolation of anything flight critical.

367
00:45:46,200 --> 00:45:46,780
Methods.

368
00:45:46,780 --> 00:45:48,320
We've talked about these at length.

369
00:45:48,320 --> 00:45:52,860
Adversarial testing, I believe, is a big key part of this.

370
00:45:53,400 --> 00:45:57,320
One thing I guess we didn't really talk about is kind of design standards.

371
00:45:58,360 --> 00:46:00,700
It's something that could be addressed as well.

372
00:46:01,080 --> 00:46:16,840
Making sure that the software as it's developed complies with the different best practice recommendation of how to develop secure software in terms of functions that are allowed and such.

373
00:46:17,180 --> 00:46:18,820
That's another potential method.

374
00:46:18,820 --> 00:46:23,740
We are more looking at the fitting things on top of what was there already.

375
00:46:27,050 --> 00:46:30,510
But we still do have a few problems that we need to solve.

376
00:46:30,830 --> 00:46:34,150
We're not going to try and pretend that we solved everything here.

377
00:46:34,150 --> 00:46:39,970
We'd like to think that we solved a significant part of aviation cybersecurity just in this talk.

378
00:46:40,830 --> 00:46:45,170
But there's a few things that we need to think about going forward.

379
00:46:45,650 --> 00:46:47,930
Supply chain security is still a concern.

380
00:46:49,790 --> 00:46:52,150
Obviously, as I said, anything can be hacked.

381
00:46:52,150 --> 00:46:57,750
As the devices are sitting in storage, an attacker could go in and modify them.

382
00:46:57,750 --> 00:47:03,490
They've got plenty of time to go in and modify them, figure out how they work.

383
00:47:03,630 --> 00:47:06,370
Either modify the software or just physically.

384
00:47:06,370 --> 00:47:08,310
Physical modifications to the hardware.

385
00:47:08,990 --> 00:47:14,690
And how to make sure that that doesn't happen or can't happen is a challenge.

386
00:47:16,150 --> 00:47:23,470
RF communication is also another area that we can't really address.

387
00:47:23,470 --> 00:47:26,090
The airplane has a fair bit of RF communication.

388
00:47:26,090 --> 00:47:32,550
It has radio, ADS-B, weather, etc.

389
00:47:32,550 --> 00:47:39,590
This is also something that wasn't addressed by what we've presented here in this talk.

390
00:47:40,850 --> 00:47:45,730
The flight crew, the pilot's training is a significant part of that.

391
00:47:45,730 --> 00:47:55,870
If there's issues with communication between the aircraft and ground, that's something where training can kick in and deal with the situation.

392
00:47:55,930 --> 00:48:02,650
But it is still something that would improve matters if there was a way to secure the communications.

393
00:48:05,750 --> 00:48:14,150
Things that we might also want to think about in the future are how often, how much change would require something to be retested, more adversarial testing.

394
00:48:14,150 --> 00:48:30,050
What level of change, where different amounts of change are considered to be minor fixes, and they don't have to require a complete redesign of the system.

395
00:48:30,410 --> 00:48:35,430
But some level of change does require a complete redesign and retesting the system.

396
00:48:35,430 --> 00:48:39,390
So that's something that would need to be looked at in the future.

397
00:48:42,200 --> 00:48:44,740
And then there's also the maintenance devices themselves.

398
00:48:44,740 --> 00:48:50,240
We talked about how maintenance devices are used to program all the different components on an aircraft.

399
00:48:50,240 --> 00:48:55,900
This means that would be used to program both flight systems and these air-gapped non-flight systems.

400
00:48:56,380 --> 00:49:00,820
So maybe those need to have a slightly different category.

401
00:49:00,820 --> 00:49:06,700
You could argue, you can put together a committee meeting and argue about lots of this stuff for a while if you want to.

402
00:49:06,760 --> 00:49:15,920
But I think that what we've given here is a fairly complete approach to address cyber security.

403
00:49:16,940 --> 00:49:18,720
Any questions?

404
00:49:18,720 --> 00:49:21,020
We'll be in the discord for any questions.