Kia ora koutou katoa. Welcome everyone. I'm David Robinson, go on the internet as the name carrot.
I'm a pen tester at ZX Security in Aotearoa New Zealand. For those who don't know where
Aotearoa is, we're at the top of the map there.
I enjoy, a little bit about me, I enjoy aviation and hacking. Queensland and Australia has a couple
of great conferences with great hacker content, but they're also on their approach path for their
local airport so you can sit on the riverbank or on the beach and watch planes come and go.
So that's a great combination there.
Today we're going to be looking at electronic flight bags in the general aviation cockpit.
We're going to go through some example issues, some vulnerabilities, some security type things,
and also going to discuss how we can mitigate the issues in each case.
I'm going to go through these in more detail as we go through the talk.
With the issues I'm going to present, we're at quite a high level for vulnerabilities.
Discuss more sort of classes and types of issues, opposed to diving down into
individual vulnerabilities. We're not going to be naming vendors or product names here.
We're going to try and keep it general so it's helpful for everyone. We're not just sort of
giving specific examples. Hopefully there's something that everyone can take away.
Sort of for a bit of a framing of the talks of the issues I'm going to present,
while I've been thinking about discussing putting this presentation together,
I've sort of gone back to the CIA triad and been focusing on their integrity and availability
sort of of the systems and how these issues sort of affect those.
I will note that a lot of these EFBs and the receivers that are used by EFBs will say,
you know, do not use for navigation or safety etc purposes. We know people are actually going
to use them. People are going to put too much trust in them. So where possible,
we should try and still make them safe if there are people using them in these situations.
So what I'd like people to take out of this talk today is some ideas about how to make more robust
and secure systems for their customers, for the pilots using their systems. There's going to be
a particular focus on general aviation EFBs, but hopefully some of these ideas can apply for
other EFB manufacturers and other parts of the aerospace industry.
To an IT security professional, most of these issues and problems are going to discuss will not be new issues.
I will be trying to put an aerospace spin and examples to them to help tie them to the aerospace industry.
But a lot of these issues, as we've seen industries move into a more digital, more connected world,
we've seen a lot of these types of issues, categories, classes of issues
come up as they've made this transition into this new digital world. So aerospace is not going to be
the first industry to go through all these growing pains, nor is it the last industry that is going to
go through this growth of product scope and have to deal with these issues.
So what is an EFB in the general aviation context? It's often going to be on a tablet.
It's going to provide the pilot with some combination of flight charts for navigation,
airport charts. It might provide some altitude and heading reference systems.
So your artificial horizon, altitude, speed, direction.
It may also provide some situational awareness through ADSV or FLAMIN.
It will be able to show the pilot what other planes and aircraft are around the plane that
they're flying. So this is how a tablet and a receiver and the sensors sort of fit together.
So in the middle we have some sort of receiver unit. These are commonly, you know, and then we'll
have the tablet with the EFB. And this communication between the receiver and the tablet slash EFB is
quite often going to be Wi-Fi. In some cases it's Bluetooth.
And between the receiver and the tablet, the most common protocol used is GDL-90.
And then some things will also use HTTP or WebSockets.
The receiver can take inputs from a variety of different sensors and inputs. So we could have
GPS satellites as one with ADSV in to help the situational awareness.
We may have a gyro and an accelerometer that will help with pitch, yaw, roll,
acceleration, deceleration. In addition to the receiver sending information to the EFB or tablet,
there may also be a web interface to the receiver where sort of configuration of the receiver can be
done. And this normally happens over HTTP. So for my testing, I sort of only used my own
tablets, my own receiver, and my own hardware. Where radio was involved, sort of, I did,
you know, I made sure that my signals did stay contained to my test environment. So I used a
Faraday cage. Where possible, I turned the transmit power down. I tried to use non-aviation
frequencies. So if I could change the frequency used by the transmitter and the receiver unit,
I would use non-aviation frequencies. Where possible, I'd directly connect the transmitter
to the receiver with a cable and some attenuators to drop. So the receiver wouldn't get burnt out
by the additional power. So I was really trying to make sure my system stayed contained
to just my test setup. So there's a variety of examples and issues I'm going to go through,
and I'm going to go through each one of these in more detail.
So first up, we're going to look at heartbeat messages.
So what this will do is the receiver will send a heartbeat message on a regular basis. The EFB
will receive the heartbeat message and use that as an indication the receiver is up
and working as expected. And it can be used to inform the pilot that the receiver is not
functioning correctly or the connection between the EFB and the receiver is not working.
So as an example, if we start an EFB and the receiver is off, we'll often get some type of
red X, some type of no connection, no heartbeat, no connection established,
some sort of error message that's quite prominent and displayed. Most of them
involved a red X. I was quite clear that the system was not ready for use.
So when we did start the receiver and the EFB connected to the receiver,
the red X went away and it started to display data. So headings, speeds, altitude, in this case.
So what happens when the heartbeat stops? This can be because we turn the receiver off.
It could also be because a malicious individual is tampering with the data in some way.
So what do people expect is going to happen?
Do they expect the EFB to inform the pilot, bring back the red cross?
Or do they think everything's just going to continue on hunky-dory?
Everything's going to be fine like nothing has happened. It's all OK.
So who picked just continue? Well, that is what happened in some cases.
When the system is an integrated state, it should tell the pilot that
the heartbeat message has gone away, that I can't trust the receiver anymore.
So when we are, you know, for these heartbeat messages, we need to make sure the EFB is
using it as an ongoing check. It's not just a check to be used to start up,
have all the components started up. It needs to be an ongoing check
to ensure that the receiver is still up and running. Because in some of these cases,
if you stop the receiver, the EFB will keep displaying the same altitude,
the same speed, or same location, rather than actually showing that there's an error.
So it needs to inform the pilot that, you know, the heartbeat has stopped being received.
And you could extend this now to start looking at other data. If you had been continuously
receiving the altitude and every message that included the altitude, then suddenly
the altitude field was no longer there. That's an indication that, again, that something's wrong,
and a piece of data that the EFB was expecting or had become used to expecting has disappeared.
Maybe it should inform the pilot that just because the altitude has disappeared,
other data may not be as of the high quality as it was before.
So the validity of data.
The data that EFBs receive from the receivers may not always be valid. Likewise, the data the
receivers receive from the sensors or other inputs may also not be correct. Receivers'
sensors have faults which could result in bad data being sent. There may be corruption happening
on the wire. A malicious individual could be injecting or intentionally manipulating the data
to make it malicious. So one example is headings. This is a test I did.
Normally a heading in aviation was between 0 and 359 degrees, or 1 and 360 degrees,
depending on the particular implementation. But whatever happens, the heading should not be more
than 360 degrees. So in one case, with a dummy receiver, I sent an EFB a message where the heading
was 450 degrees. It was actually remapped and displayed as 90 degrees, which if you take a
step back and you think about the underlying math libraries which EFB may be using, when you talk
about degrees and degree maths, 90 degrees makes sense because you've got 450 degrees.
So you go 360 for a whole circle, then another 90 degrees, 450. In the math domain,
when you're dealing with angles, that makes sense. But in the aviation domain, yes,
headings are measured as degrees, but we're dealing with headings, not degrees. So in this case,
in aviation, it's 360 degrees. So if it's more than that, we know it's actually an error.
So if we take a quick step away from EFBs and we think about another system where
there can be pilots presented with information in their user interface, which informs the pilot
that there is a disagreement, there is an issue with a sensor. A recent case has been with the
737 MAX and the MCAS. One of the things have come out that the angle of attack
indicator, the AOA, there's a disagree warning. This was an optional extra that airlines could select.
And I understand in the MCAS changes, this warning is now
going to be implemented on all 737 MAX aircraft. And what this warning does was
displaying that when the sensors no longer, seen as multiple AOA sensors on an aircraft,
when the values differed, it was going to warn the pilot there was a disagreement.
So the pilots knew that this piece of data could not be no longer valid and maybe they
need to use other sources to cross reference and understand what the issue was.
So it would be good if AFBs, when they start to detect the data may no longer be valid,
it's gone out of bounds, it's not what they expect, there's a disagreement. It'd be good to see if
there was a type of warning, you know, if an AFB could provide some sort of warning as the 737 MAX
does with AOA disagreement as one sort of recent example. So this can be, you know,
when they start to disagree or they go out of bounds, like the headings of the 450 degrees,
it's out of bounds, it's an indication there should be an error.
So what AFBs and receivers should do is they should know what the data should look like
under normal operation. You know, they should be checking that their expected data,
is it in the correct range? And when it's out of range, inform the pilots somehow or stop the
information being sent so people cannot make the wrong decisions about it. Or you know that
you shouldn't be relying on a sensor that is having a fault. Additionally, you can look at the trends
in the data. You know, if the vertical speed results in an altitude change that's
completely out of bounds, maybe you should stop displaying altitude or vertical speed.
So for instance, if your altitude suddenly changes 10,000 feet in a few seconds, either
there's a fault with the plane and the pilot already knows about it because the plane is
dropping out of the sky, or there is a fault with the receiver or the altitude system somehow.
In that case, you should inform the pilot, don't trust this altitude,
go trust one of the other instruments that is giving you altitude and rely on that.
And it may indicate that other sensors involved, which the EFB users, may also be
invalid and the pilot should not rely on them. So with the situational awareness that pilots
can have of the aircraft around them, there are some sort of denial of service scenarios.
So what some EFBs do is they have a movie map, which is normally for navigation,
showing you where the navigational aids are, showing you your route.
But additionally, if the system is capable of ADS-B, it can start showing the other aircraft
around and where they are. And with software defined radio, it's easy to transmit ADS-B out.
RenderMan and others have discussed this previously at many other conferences,
and I believe there's some other talks at Aerospace Village on ADS-B spoofing as well.
So this is sort of roughly what it looks like. We've got a movie map,
we've got the aircraft, we've got its route, and we've got some other planes around it.
So what I did was I did a situation where we had this plane and I
injected a large number of planes around it. So it's going to be really congested,
super congested airspace. Lots of conflicts, lots of potential path crossings, a lot of potential
hazards. So when I broadcasted this, I was expecting the EFB to show all the planes that
I broadcasted. But in some cases, you know, on the right there in the diagram I've just popped up,
it doesn't actually necessarily display all the planes. Some of the planes were being dropped off
and missing. It wasn't always the furthest ones away that disappeared, so it wasn't
some sort of range thing of there's too many planes. I only showed the closest X number of planes.
I couldn't really determine a pattern that resulted that
of what planes were missing. And also, if I replayed the same input data into the system,
I wouldn't necessarily get the same output. So without sort of further research and diving into
the code, my current hypothesis is it's something to do with the way that the timing of the message
received and how it packages up X number of planes to send down every half a second or every 10
milliseconds, depending on how often it sent the current list of planes, and there was some
cut off in buffers. That's my hypothesis. I'm not entirely sure. It's just saw this pattern
of indiscriminate planes being dropped off. And this ABSV spoofing that can be combined
with TCAS issues. I think Pentest partners, Ken, talked about this back in May. I believe
there's also a talk going on during this aerospace village about this in more depth.
But what I'll say on this is with ADSV and TCAS, TCAS is the traffic collision avoidance system,
that you can actually help. You can start putting in malicious ADSV targets to help
reinforce the pilot. There is actually a real TCAS issue. It's not a malicious one,
because you can make the two sources correlate with each other. So you could have a malicious
plane come in and then you'd start to get TCAS messages maliciously, which will come in and
reinforce that as well. So whilst discussing some TCASes, TCAS in some instances from what I understand
has directional antennas, so it can tell where the TCAS message is coming from, whether it's to the
left or whether it's to the right or up or down and so on. We could do the same with ADSV antennas,
so we know where the aircraft should be based on its location in the ADSV message,
but we could also look at the direction the signal is coming from to ascertain if
I believe the plane's over there and the signal is coming from over there, so that they most
probably correspond. But if the plane's over there and the signal is coming from another direction,
we know that possibly this is a malicious ADSV message. So if we've got that, we can rule them out.
And the ADSV receivers, when they are not going to pass down a full set of aircraft as
they're somehow dropping aircraft, it needs to inform the downstream systems, in this case the EFB,
that there is an issue and it is operating in a degraded state.
Additionally, if the EFB is dropping planes because of some limitation it has,
it should also display some indication that planes are missing from the display and
do not use this as a situational awareness tool at the moment.
So GPS spoofing. From what my testing and from what I've seen,
GPS jamming, GPS signal loss are sort of handled quite well in the EFBs.
There's normally indicators that there is a GPS fix,
and there is also an example when there is no GPS fix, there's an indication.
But when we send malicious GPS signals, this is not the case.
So when we send a malicious GPS signal, what I'm thinking of is sending a valid GPS signal
replicating a set of satellites, which result in the aircraft determining the wrong position.
So at last year's Aviation Village, there was a talk on ILS spoofing,
which involved in the result of aircraft potentially having the wrong horizontal offsets
or the wrong glide slope, and resulting the planes landing in the wrong location.
One of the cases here was, oh, GPS and GNSS, RNAV, can be used to cross reference,
you know, the glide slope and stuff, so they should be lining up, and if they don't line up,
they can alert the pilot, and they can make further decisions about going round
and ascertaining what their navigation systems are. But we could also use GPS spoofing
to match up with the ILS spoofing, so they're actually going to correspond. This cross check
no longer becomes a cross check because they're both incorrect.
But they're both incorrect, but they're both showing the same values, so
there is no cross check, and there's no indication that one of them is wrong.
So back in 2017 at DEF CON, I did a talk where I was doing some GPS spoofing research
that was mainly based around time and manipulation of time servers.
But what I did during that thing, during that research, was I looked at how we could go about
detecting GPS spoofing. And in that case, I came up with a bit of a proof of concept tool
called GPS Snitch. It's not production ready, but what it was is looking at some of the GPS
parameters, signal parameters, and so it was possible to actually detect when GPS spoofing
was happening. So for a start, the maths is all based around the GPS satellites broadcasting
a very accurate time, and then based on the time offsets between the different satellites,
math happens and you get a location.
So if we've got a clock on the receiver that is being synced up with the GPS when we first
turned it on, the time should stay in sync together. But if we suddenly start GPS spoofing
and the GPS receiver locks onto this spoof set of signals from a range of spoof satellites,
we'll notice the time will jump, and it might be 10 milliseconds ahead of time,
5 milliseconds slow. But if we get sudden change in time, that's an indication that a spoofing
has happened. Because trying to start up and have a spoofing attack start with a time with
sub millisecond accuracy is quite a difficult task.
And that's one parameter. There's other parameters, and I found
that actually when you looked at more parameters, it was actually you get a much more stable
system, particularly if you're leaving it running. You know, during my test I left it
running for a day just to see what the natural variations were, and I found that sort of one
look at one attribute wasn't really enough. You need to look at a range of attributes.
So if you're in a case in an aircraft, if the location changes more than what the current
speed allows, that's an indication that, you know, it could be GPS spoofing. Because you know your
velocity, and if it changes, if you're outside of that, you've got a sort of a circle of uncertainty
which may be valid, and if you're outside that, that's a potential issue. Also looking at the
GPS signal strength. GPS satellites are 20,000-ish kilometers away, give or take a bit,
so the overall strength of the GPS signal when it gets down to ground level is very low.
So suddenly if we get a GPS signal suddenly raising strength a lot, that's possibly an
indication that a GPS spoofing attack is happening, because the transmitter of the
fake GPS satellites is going to be much closer. So matching the signal strength is hard. Additionally,
we should have a range of signal strengths, because the satellites directly overhead seem
they are closer than the ones way out at the horizon. They're going to have different
signal strengths because the distance traveled and the amount of atmosphere they have to travel through.
But suddenly if the range of different signal strengths decreases, that's another indication
that a malicious GPS transmission is happening, because when you're doing the malicious
transmission chances are it's all coming from one transmitter and it's going to have a very
similar signal strength. Additionally, like we said back with the TCAS and the GPS was
again looking at the signal direction. We know where the GPS satellites should be at any given
time. We know the plane's current location. So we know in what direction the GPS signal
should be coming from for each of the satellites. So if they don't come from the expected direction,
it's an indication that there might be GPS spoofing or a GPS attack happening.
So what we need to do to help mitigate some of this risk in the EFBs is they need
in the receivers, they need to start monitoring GPS for abnormalities.
So like with some of the topics I talked about with the GPS snitch.
Show an indicator that when you have no GPS fix, when you detect the spoofing,
display GPS no GPS fix because you can no longer trust that as an input. Mark it as no GPS fix
or degraded GPS fix or something whatever meets the relevant terminology and
accuracy standards. So integrity of the data. The data sort of in the overall system of receivers
and EFBs and sensors, it's nearly always happening in clear text. There is an encrypted version of
GDL 90, but from what I saw that was not in very common use. My guess is it's a bit of a chicken
egg problem. The receiver manufacturers don't see the point in implementing it because none of the
receivers, sorry, none of the EFBs are implementing it. EFB manufacturers don't
implement it because none of the receiver manufacturers have implemented it.
Additionally, the Wi-Fi is often open and in clear text, so anyone within range can connect to it
with no authentication required.
And also there is when you first sort of pair an EFB and a receiver, there's no key material
changed. So you can switch out the receiver and the EFB will still keep talking to it. If it's the same
SSID for the Wi-Fi, the same Wi-Fi password, it will just connect fine.
It won't inform the pilot. So, you know, think back to your headphones and your phone.
When you get a new set of Bluetooth headphones, you need to pair your headphones and your phone
and they're connected and they're only going to talk to each other.
You know, if you didn't pair them and you didn't have the sort of checking that they're talking
to each other, as you're walking down the street listening to music, you'd start hearing the music
of everyone walking past you. You know, and we don't want that to happen with our EFB.
We want to make sure we're getting the data from our own plane, not our friend's plane.
So, you know, if you have a friend who you're doing some formational flying with
and because you're friends, you've discussed receivers and you've
settled on the same sort of receivers and EFBs because you both like them.
You don't want the situation that if everyone's left it with the default Wi-Fis
and the default SSIDs because it just starts working, you don't want the EFB in one aircraft
connecting to the Wi-Fi in another aircraft around it.
Because that's going to be bad if you're receiving data for a different aircraft.
So what we should look at here is, where possible, start making the migration to GDL 90.
Have receivers start to say, you know, on this date, we're going to implement it. On this date,
further down the track, we're only going to have GDL 90. Likewise, on the EFB front, make sure
you know your systems are set up to actually accept it.
When you first pair an EFB and a receiver, make sure there is some exchange of key material.
Make sure there is a pairing process to couple them together so you can't introduce a
malicious receiver and have the EFB connect with no error messages.
Make sure you sign every message so the EFB can trust that it is coming from a receiver.
That it trusts. If the message is not signed, disregard it.
And additionally, ensure there's some protection against replay attacks. So
make sure that a malicious event that you can't capture a packet or a series of packets
and just replay those over and over and over again.
Make sure there is some protection that they need to actually keep changing it as it is rolling.
So device hardening is part of my job. I look at devices, systems, hardware and to make sure they
are robust. You know, there's testing to make sure they've got vulnerabilities, but also checking that
they're robust. So even if they're vulnerabilities, I don't know about their attack footprint is as
small as possible. And when I was looking at some of those of the receiver devices, I was
put this hat on. I was thinking, you know, have they made the attack footprint as small as possible?
In some cases, you know, they had made the attack footprint bigger than it could have been.
For instance, you know, there was a receiver that had an internal fan and based on the
receiver's temperature, it would put the fan speed up and down to keep the system at
the optimal temperature. But instead of setting it up so the fan controller only listened to
commands coming from inside the device, they configured it so it would accept commands
from anywhere in the Wi-Fi network. You know, and that's wrong because in case the only thing
the fan controller should be receiving commands from is the temperature sensor inside the receiver.
So when the temperature sensor noticed the temperature raising, it needed to tell the fan to
go faster and vice versa. Additionally, they're all weak. Wi-Fi configs, as mentioned before,
a lot of them are open. They don't have pre-shared keys. They don't use WPA2, WPA3.
You know, using pre-shared keys, they will
put protection on it. So A, it will encrypt most of the data. B, it will mean that only
authorized people can connect to that Wi-Fi network. So you won't have
malicious and rogue things connecting to the Wi-Fi network.
Though even with the encryption, even with the WPA, WPA2, there's still some attacks you can do
against it which can have downsides. For instance, there's management frames which
are sort of below the data and control the Wi-Fi connection. And there's a particular
message called a deauthentication packet. And what that does, it's sent from the access point
to the receiver. So the access point, in this case, would be the receiver device and the
wireless client would be the tablet slash EFB. And what the access point says is say, normally you'll
say, hey, please disconnect, re-establish, because I want you to re-authenticate.
So provide me with the password and whatever again.
My problem is, is these messages aren't signed normally. So anyone
could come along and send deauthentication packets. And this results in two possible
cases that you get a denial of service because the EFB or tablet will no longer be able to connect.
It just keeps being told to re-authenticate. So I'll go, I'll connect, get a packet, say
re-authenticate, so disconnect, deauthenticate and re-authenticate again.
Additionally, it can also be used to steer the device instead of talking to a legitimate receiver.
There might be a malicious receiver. So what you do is when it's connected to the legitimate
receiver, you send deauthentication packets. When it's connected to the malicious receiver,
you don't send deauthentication packets. So it stays connected to that. So the EFB is receiving
data from the malicious receiver rather than the receiver that the pilot put there.
There's also additional services running. SSH is a common tool used for remote access to a device
for configuration. So in essence, production devices don't need SSH enabled at all because
they should be in a sort of secure, hardened format. When it's not an active development
or active debug, you don't need the sort of access to the device. And even digging into further,
its configuration is not in line with sort of best practices for the use case.
Sort of in following hardening guides, they sort of had basic things like port 14 turned on,
route logons turned on, a lot of things that you wouldn't normally see in something. You'd
see it in the default sort of installs just to make it work, but it hasn't shown the additional
hardening steps that have gone through. Also, the web config user interface had no password on first
use, no password change on first use, no password at all. So even if the Wi-Fi network had a
pre-shared key and password, as I mentioned on the previous slide, you should also have
a password on the web UI to control the configuration of the receiver. This is so
we have security in there, so it's got multiple layers of security control. So if one fails,
it's still a safety net to stop it stopping the malicious individual getting further
into the system. Make sure you have the safety nets just to make sure things don't happen.
So with this is make sure that you seek advice on how to harden the configuration.
Make sure their attack footprint is as small as possible. If components have hardening guides,
make sure those are read and followed through and used to make the device as secure as possible.
So password management. So as I just said, web UIs often didn't have passwords on them or didn't
prompt for a password change on first use.
Going back to the Wi-Fi case I've used a few times now. There is sometimes options to enable
Wi-Fi encryption with WPA2, WPA3 or with pre-shared keys.
One when it did this said, came off a message saying we've securely set up your Wi-Fi. You're
only going to show you this password the once. If you forget it, you'll need to do a factory reset.
So I went through, I factory reset it again.
Try setting up the Wi-Fi. Comes up the same password.
Go across to a different instance of the same device.
Gives me the same password. So instead of being randomly generated, this password was hardcoded.
It always gave you the same password to be used for the Wi-Fi.
And hardcoded passwords, that is a bad thing.
Additionally, in this case, I found it a little bit worse was because the text and the messaging around the password setup
gave the user their experience that this was actually going to be a unique password.
It was sort of randomly generated.
It was secure, when in actual fact it wasn't. And that's sort of a double...
makes it sort of doubly bad because the pilot or the user is not actually being provided with the correct information.
So they can't make the correct decisions if they've been provided with incorrect
input information or documentation.
So if there is a hardcoded password that you're going to use, say it's a hardcoded password and recommend that
the users actually set their own password. Or better yet, just randomly set a random password.
Give them a QR code that you can scan, because most tablets and phones these days can read a QR code with
a Wi-Fi password in and set the Wi-Fi up without actually having to type in a long password.
You can just scan a QR code.
Some of the EFB applications had companion websites.
You had to sign up some of the times because the EFBs would not work without them,
because they had some sort of subscription functionality that free users...
you only saw so much paid users use this, or you had to be a paid user depending on the thing.
This allowed for flight plans or additional up-to-date weather information,
sort of other non-free services that it gave you. I did not test any of these companion websites.
I only went as far as registering an account on these websites.
I noticed there were some issues. In one case I got emailed a password in clear text,
which to me as a pen tester often means that passwords are not being correctly stored
in the database. The fact that a clear text password can be sent via email, so that's a sign
that incorrect password storage has been used. Additionally, you also saw some that allowed for
weak passwords, so passwords that don't meet the standards of what people think is a strong
password these days. Additionally, had some that said, well, don't use any special characters.
So putting my pen tester hat on, if I see a password field or some other user input field
that says, oh, don't use quote marks, don't use dashes, and don't use these sort of other symbols,
to me that's a red flag that SQL injection might be available. They're trying to protect SQL
injection by just not allowing users to use these characters. So, you know, if I was testing this
for a job at work, if I saw text like don't use the quote mark, first thing I'm going to do is
test SQL injection on it because chances are that's why that message is there. So password
management. OWASP, the Open Web Application Security Project Foundation, has a range of
great check sheets and these uncover password storage, password management, authentication,
along with a range of other really helpful documentations. They've got stuff around
building more secure web apps. Additionally, they've also got stuff on building secure mobile
apps, which most AFBs are. So that's a great resource for information.
So hopefully these example issues and solutions have helped you. And you've gone away, you've
got some ideas that you want to look into in your own products some more. And I hope that
as you do future development, as you add features, as you test functionality, that you think, oh,
what could a malicious individual do with this? You know, is there a way that they could affect
their integrity or their availability of the system with what they could do? Sort of having
the sort of what-if hacker mindset and hopefully you can bring some of that into your testing
and your development. Also, what can the security industry do to help the aerospace industry in this
regard? What help would you like from us? You know, would some example test cases of this
malicious thinking be useful? So as an FB or receiver manufacturer, you can take these
test cases on board and start working them into your systems. Would a test harness that
was, say, a dummy receiver which talked GDL-90, but instead of just sending sort of valid,
helpful GDL-90, also sent malicious payloads and started pushing the boundaries a bit more.
Would that be something that was helpful? That you could set up this test harness for this
receiver, connect your FB to it and have it send all this malicious information to help you if
the automation of the testing. Would that be something that's helped? So really good to hear
some feedback from the industry about what you need from us as well. So, thank you. Hopefully
it's been useful for everyone. I'd really love to hear feedback, chat to some people, because
if I'm passionate about it, I'm sure there are other people here out there who are interested
about it. Or that's why you came along and listened to this talk. Thank you very much.
See you all later.