 Hi and welcome to Defending the Unmanned Aerial Vehicle Advancements in UAV Intrusion Detection. My name is Jason Whalen. I'm a Master of Science student in the Advanced Networking Technologies and Security Research Lab at Ontario Tech University in Ontario, Canada. We'll be spending the next 20 minutes or so discussing why an intrusion detection system for UAVs is needed, proposed solutions and academics, how these solutions can be used in practice, and finally, I'll be demonstrating our fully developed novelty-based IDS. So let's start off with a brief background into the threats unmanned aerial systems as a whole are faced with. This isn't a comprehensive list by any means, but it should provide some insight into why an IDS for UAVs is needed. The information here comes from experience with pen testing at commercial UAS, as well as research in the UAV security domain as a whole. So insider threats are, of course, possible with any human operator. These can occur when the operator executes missions or payloads in a rogue manner without authorization. Initiation mechanisms for insider threats can include multiple sign-offs on certain actions, alerting one of the UAV deviates from the initial mission, etc. The ground control station requires internal network security controls to allow for only authorized personnel to have access to the operational systems, which could also include physical security to this location. And some autonomous unmanned aerial systems, remote ground control stations will be deployed to allow for remote charging or payload downloads. In this case, these remote stations could be in very remote areas, sometimes even hostile locations. So for this reason, physical security is very important, as is both wired and wireless security. So something as simple as connecting to a network weather station could lead to complete compromise if the wrong person connects to it. Many systems will also make use of web or cloud infrastructure, either for backend processing or something like a client reporting portal. So similarly to the ground control station being a traditional IT system, best practices in web and cloud security also apply here. So even if this infrastructure doesn't have any direct connection over the or control over the UAV or connection to the UAV, there can also be private customer reports or other sensitive information that could be a target. So the other prominent threat here is if there is any connection between the cloud and the UAS, given the potential for the interaction with the UAV. Commercial off the shelf intrusion detection systems can of course be integrated into this type of infrastructure, as it's just a traditional IT system. So communication links. This is where things become more complicated. Given that the UAV is essentially a flying computer is exposed to threats to various wireless communications. Autonomous UAVs may use 802.11 Wi-Fi for payload download at remote ground control stations, which can easily be compromised if using something like WAP or WPA2, especially with the new PMK attack. GPS jamming and spoofing are well understood and well known attacks are becoming more and more common. Other wireless data links such as cellular or RF can suffer from denial of service and jamming attacks. And communication protocols themselves can also have inherent vulnerabilities such as MAV Link version 1 and ZigBee with many very vulnerabilities including eavesdropping, hand injection, replay attacks and more. Communications dealing with collision avoidance can also cause trajectory modifications such as if ADS-B spoofing and if ADS-B is used as direct feedback automatically by the UAV. So the UAV itself, given that it's arguably the most accessible for attackers, it suffers from its own vulnerabilities as well. Depending on how collision avoidance is implemented, if it reacts in a predictable manner it can be exploited to actually hijack the UAV, especially in an intruder and pursuer type of scenario. If an attacker is able to communicate with the UAV directly, it also opens up the underlying system for attacks. So some of these potential vulnerabilities would include command injection, buffer overflows and open and accessible services that were originally for debugging that have been left behind. And finally, sensor-based attacks are very common and are well researched as well. So some of these attacks can include optical flow sensors spoofing and jamming and those targeting communication sensors such as ADS-B or GPS. There's some key takeaways from conducting a threat analysis which point to the need for an intrusion detection system. But I think it's safe to say that most small to medium sized UAV technology developers are focused on getting the product to the market, not necessarily with security. And the more traditional IT systems such as the ground control station in the cloud, mobile applications, all these can follow well-defined industry best practices and even implement commercial off-the-shelf intrusion detection systems. But the UAV itself faces the largest threat landscape within the UAS given its often hostile operating environments, its physical accessibility, and its reliance on wireless technologies. However, the UAV itself requires its own unique IDS solution. It's a cyber-physical system with varying communication protocols, control configurations, frame types, flight firmware, and more making it very difficult to make one size fits all IDS. So although there's a need for intrusion detection system for UAVs, there's also a number of challenges in developing one. Many of these challenges are similar to the robotics or internet of things domains with size and weight constraints being primary as well as computational power limitations. So this is especially true if an IDS agent is to be run on board the UAV given that many of the prominent attacks result in denial of service such as jamming. This does actually suggest the need for an onboard agent that can continue to detect attacks and potentially mitigate them even if that link is under duress from such an attack. These constraints, if not taken into consideration, can result in computational bottlenecks and can negatively impact flight performance. So finally, given the wide variety of onboard components, UAV frames, communication protocols, and so on, making a ubiquitous IDS that can be applied beyond a single UAV becomes very difficult. And this especially applies to machine learning-based intrusion detection techniques given the lack of a labeled dataset or even a dataset that have anomalies in them. So UAV intrusion detection is an emerging area. It's currently being investigated primarily in academics. And sometimes academic proposals don't offer many practical takeaways, which is what I'm trying to cover here. So initial work in this area utilize game theory-based approaches. These stem from low-power and low-resource environments of the Internet of Things where game theory and Beijing games are used. So depending on the result of the game, further more costly techniques can be deployed. For example, signature or anomaly-based detection. And sometimes certain defenses will also be applied based on the result of the game. So some pros of these different game theory techniques are that they're highly efficient and they require low maintenance depending on if there is a secondary detection technique and what that is. And obviously, if it deploys a signature-based model or something similar, it would require ongoing maintenance in order to stay up to date. And as you require multiple participants in the game, many of these solutions are only applicable in the context of mobile ad hoc networks or multi-UAV scenarios where we're expecting to have another node within our mesh to go rogue or become malicious. And this isn't always the case. Sometimes we have lone UAVs that are autonomous and are acting by themselves. In implementations where defenses are deployed, depending on the result of a game, sometimes the game loss can leave the attack completely undetected or the sensors completely vulnerable. So specification-based approaches work by defining behavior specifications and using them as the basis for detecting attacks. Think signatures, but for actions instead of inherent traits within actual network protocols. So these actions can include certain states or transitions. Some examples would include defining acceptable flight paths or sensor values or creating a whitelist and blacklist of various values or transitions. These approaches offer low-false positives since they're only really being triggered upon the violation of a specification that you've made. They're also straightforward and simple to implement. There are, however, high setup and maintenance costs as you have to actually determine what those values are yourself and you have to update them when necessary. And a specification-based intrusion detection system can only detect what you define and nothing more. So if an unknown attack or a variation of an attack occurs, the IDS has no way of detecting it. Anomaly-based techniques have been investigated more recently and these utilize various machine learning and statistical techniques in order to detect anomalies within the UAV, which maybe indicators on the attack. So some examples of techniques in academic literature include things like multiclass support vector machines, deep belief networks, isolation forests, and so on. So pros of these techniques are that they possess the ability to detect previously unseen attacks, possibly depending on how they're implemented, and those that affect more than just state or transitional changes. And they're much less of the manual process because it's all done through a training process instead of going through and manually selecting values. Unfortunately, though, they require either a labeled dataset or a dataset that contains anomalies so that they can be classified. In order to get these, you need a UAV equipped with different sensors. You need to be able to conduct the attacks against it in order to gather that data. And obviously, this can be costly and some of these attacks introduce legal issues and so on. So the detection of new attacks would also require the same process all over again, resulting in high maintenance eventually. So hybrid approaches make use of two or more detection methods and aimed to provide the benefits of detecting unknown attacks with low false positive rates. Usually they have a low computational cost method that's employed first, followed by a more costly method depending on the result of the first. So for example, if an attack does not match a signature, then maybe the secondary anomaly detection might be invoked after. Pros of hybrid approaches are that with a combination of multiple methods, they can gain a maximum accuracy with low false positives and also low energy consumption and computational costs. There are cons again here though, such as high maintenance depending on the ensemble that was made and if the initial detection is incorrect then the secondary may never be invoked failing to detect the attack altogether. More recently, novelty-based detection has been introduced in UAV space which is similar to anomaly detection but with some key differences. So an anomaly is defined as a rare observation outside of the norm that exists within the training set and are classified or clustered, whereas novelties are rare observations detected by means of only observing normal data through the training process which can then be used by machinery algorithms to be classified as novelties requiring only a benign data set. So this allows for the use of flight logs which are created by most UAVs by default and the classifier can be trained specifically for the UAV it's operating on with little maintenance or overhead depending on the implementation. At the time of writing, there's only been one publication related to novelty-based intrusion detection in UAVs which lacks significant detail and results. However, obviously we've since published something a little bit more in depth. So can we develop a novelty-based IDS and if so, how accurate would it be? So we investigated this by developing MAV IDS which is an IDS for UAVs that use the MAV link communication protocol. It utilizes one class classifiers for detection which allow for a more ubiquitous solution. And as mentioned previously, it would only require flight logs from a flight where no attacks are experienced and a companion computer for the agent. It consists of a ground control station portal and an onboard agent. And the portal allows the operator to change settings, view and respond to alerts and trigger or abort mitigation actions. The onboard agent is used to detect attacks by receiving a stream of system messages from the flight controller using something like FAST RTSP. And this allows for the detection of attacks even when the communication to the ground control station is lost due to jamming or a denial of service attack. And this hook into the flight controller also allows the IDS to inject flight commands back. So we can implement mitigation actions autonomously if the portal can't be reached such as changing the flight mode or disabling a certain sensor temporarily. So in order to begin developing this IDS, we need data to work with. So we require flight logs whereby the UAV does not experience any attacks as our benign training flight. And we also require logs where the attack did occur mostly just for testing purposes. So obviously this is only necessary for the purposes of initial training and scoring and gathering performance. But once we do that, we only need a log with benign data. So to get live data, we assembled a small quadcopter with various onboard components to help test multiple attacks. So we want to use something open source to make it easier to develop on. So we use the Hollybro S500 frame, a PIXHawk 4 flight controller, Mavelink and other open source components as well as a GPS sensor, ADSB, optical flow and all kinds of other sensors that we can utilize in order to actually conduct attacks against the UAV and these different sensors. So we decided on two common attacks for initial testing which were GPS spoofing and GPS jamming because they're by far the most common. And just a quick disclaimer, all the flights and all the attacks were conducted in a fair day environment safely and legally within a research facility that cannot get any sort of RF data from the outside. So because we conducted the experiments in an area that couldn't get natural GPS signals, we need to generate our own to act as a ground truth. So for this, we use the Keysight signal generator which is shown on the right and that was broadcasting a location in Shanghai, China. And then to conduct spoofing, we use the open source GPS SCR SIM utility and a HACCRF to broadcast a location closer to the university later on during the flight. And jamming was also done using the HACCRF but by broadcasting light Gaussian noise through the use of a new radio companion. And these flights were approximately 10 minutes in duration and both the spoofing and the jamming caused the UAV to lose control and eventually crash. So the jamming definitely caused it to crash immediately. And as you can see here, it's tethered. So the spoofing, it would kind of drift off course and then it would grab on the tether and crash. So you can see the Keysight signal generator there, the directional antenna at the bottom and then our own device in order to actually be able to truly read what the GPS signals are without relying on the UAV and its sensor. So now that we have data, we need to pre-process it before we can use it for training or inference with the classifier. So after the training flight, the logs are downloaded from the UAV which are in Ulog format. And using a PX4 tool, they can be separated into CSV files per your message, which are essentially system messages and sorted by the timestamp, although the polling rates still vary. So the flight controller might request certain system states at varying times. So once we have the CSV files, we can cluster them based on the sensor or system component, such as the GPS system, the telemetry radio, et cetera. And this is done by setting the timestamp as the index and sorting. And then we imply linear interpolation of any not a number or absent values. And then we remove any not a number or infinity values. And so this results in one condensed CSV containing all the features and values related to a specific component. And these values are then standardized into Z scores, which helps to keep them all on similar scales. And this is really important because in the next step, when we apply a principal component analysis, if the values are on various scales, and this can lead to misrepresenting the actual influence of a specific feature, right? So we apply principal component analysis to avoid the need for manual feature selection and also to reduce the number of features which would inherently make it more efficient. So a defined variance percentage is given depending on the attack. And in some cases, this reduced the number of features from as many as 83 down to as little as 13. So as you can see here on the left side, this is some features before standardizations. You can see how the scales are very, are completely various. Like we have one that goes from 46,000 to 60,000. Another that is at 0.1 to 0 to 0.05. So the scales are huge and different. And so when we standardize this, it keeps the scales relatively equal. And in that sense, when we do do the principal component analysis, the variations are actually more accurate and true. And on the right-hand side here, we've graphed three principal components with the benign and malicious labels on top of them. So you can see that it is quite obvious when an attack happens. You can definitely spot it. So now that we have pre-processed data, the one-class classifiers can then be trained. So we selected three classifiers with each following into one of the types of one-class classification approaches. And this was done again in understanding which type of one-class classifier would perform best. So the first is local outlier factor, which is a density-based classifier. And it identifies the density of an observation and compares that to its neighbors. And a point that's less dense than its neighbors is likely an outlier. However, it's known not to perform too well on the highly dimensional data. For boundary-based classifiers, they essentially create boundaries between points, separating them into different classes. And one-class port vector machine is an unsupervised algorithm which is trained only on the normal data. And it learns the support of the observations in order to separate between normal and abnormal classes. It typically performs a little bit better on higher-dimensional data. An autoencoder is an artificial neural network with an architecture that imposes an informational bottleneck to force a compression of the input. So basically, we have the same number of input and output nodes with a smaller number of nodes in the hidden layer in the middle. So this forces it to learn from the input and then it attempts to reconstruct it and then we calculate the loss. So classification for this, we utilize a threshold to determine if the error is high enough, sorry, to be considered a novelty. So here's an overview of how the MAV IDS system works together. Now we have all these different components. So there's multiple steps and you can kind of see the pretty simple flow. So first we conduct a benign flight and we download the log from the UAV. So a benign flight is one where no attack occurs. Pretty simple, you just fly around for 20 minutes or so. We download the log. So now that what the logs extracted or downloaded, sorry, we extract it into several CSVs per system message type, then the logs are interpolated such that any non-existent values or infinity values are removed and logs related to the same sensor or component are clustered together and PCA is applied. So now we have a training set which we can use to train the classifiers and the model that's generated is then uploaded to the onboard agent for inference. And during flight inference is done on the stream of incoming messages right to the onboard agent. And if an attack is detected, then this is communicated to the ground control station or mitigation action is invoked. So a little bit about the portal and the agent briefly. The portal uses Python, the Django framework, Bootstrap, Scikit-Learn, and TensorFlow, so all open source frameworks which allows us to have a native Python app built right into the web app. So any of the machine learning code we're using is all native Python as well. It facilitates the training and tuning process, the communication to the onboard agent, changing the various states and actions and so on. And it communicates to the onboard agent via a defined message in a custom Mavelink dialog. The companion computer connects to the telemetry port on the flight controller and it receives essentially a mirror of the Mavelink and your messages, so kind of like a span port. And it clusters, standardizes all those features and then it applies PCA using the same number of principal components that were determined during training. And when an attack is detected, it communicates the alert to the ground control station. If no response is received, it will initiate the user-defined default action. So here's a look at the training page at the ground control station portal which allows the user to select classifiers and set any known hyperparameters. Then they can upload their benign flight log and begin training and view the progress on the right-hand side pane. The settings view allows for the user to select which attacks to create models for. This dictates which sensor or component to use when clustering the logs together. And there's also a number of default mitigation actions to select which are invoked after the time below. So for example, if a jamming attack happens and sends that alert back to the ground control station, if the operator doesn't respond or override that, it will implement the default action automatically without input from the operator. This is the dashboard. We can see all the active alerts coming in on the left-hand side. The certainty that the machine learning algorithm was able to determine. And we can also select some actions or mitigation actions and we can override them. And if we don't override them, then the timer will expire and the UAV will, or the onboard agent will execute it regardless if the operator is able to respond or not. Because of course, if it's jamming, they may not even be able to communicate with the UAV anymore. So the auto encoder performed the best in both computational and detection performance, representing a macro average F1 score of up to 90.57% and 94.3% for live GPS spoofing and jamming respectively, followed by the one class support vector machine and lastly, local outlier factor. And this was kind of expected. So here's a look at the computational performance with the auto encoder performing best yet again. And the atomic prediction latency represents the time it takes to conduct a single prediction, whereas the prediction throughput is how many predictions can be done within one second. So this is an important metric because the throughput needs to be high enough to not cause a bottleneck on normal operations on the UAV. And through our flights, we calculated that the average number of Mavelink messages per second for our flights are approximately 320. So as long as they're over 320, then they'll perform fast enough to not cause any sort of bottleneck. So in conclusion, there's a couple takeaways. One, the UAV has a large threat surface of many vulnerabilities coming from underlying technologies and other components of the UAS can of course be addressed with commercial off the shelf intrusion detection systems but not the UAV. So work is being done in the UAV IDS space primarily in academics. And we've shown that novelty based intrusion detection provides a number of benefits as shown to be effective especially when using an autoencoder. Onboard agents can allow for the detection and potential mitigation of attacks autonomously and during duress. And then just a little side note here, the same approach could also be used in other areas. So for example, to detect component failures. So for example, if you have abnormal amount of motor vibrations, the same technique could be used to detect that as well. So yeah, thank you so much for attending. I will be on Discord to answer any questions. So feel free to ping me there. Thank you.