UAS cybersecurity
UAT 367 Cybersecurity, Command and Control Links and Unmanned Aircraft Systems Traffic Management
Lesson
By the end of this module you will be able to
- Identify the attack surface of a UAS, from the aircraft, ground station and links to servers and the supply chain
- Analyse threats with STRIDE on a data-flow diagram with trust boundaries
- Rank risks by likelihood multiplied by impact
- Design defense in depth and state the limits of the independence assumption
Why this matters
A medical delivery drone flying beyond visual line of sight (BVLOS) relies on computers and networks at every step, from receiving its flight plan to sending commands and returning video. If an attacker can forge commands or make the drone lose track of its position, the damage is not just to data: it is an aircraft falling on people, or medicine that never reaches a patient. The reviews by AlTawy and Youssef (2017) and Wang et al. (2023) therefore treat drone cybersecurity as a flight safety issue too.
UAT 105 covered the CIA triad and HMAC; this course moves on to analysing a real system as a whole. The whole course uses one hypothetical case: a BVLOS medical delivery network flying from a provincial hospital to three sub-district health centres, using dual C2 paths (radio and LTE) and connected to a traffic management provider in a trial area. All numbers are made up for practice. The Python code for every module can be downloaded from /downloads/uat-367/.
Attack surface and trust boundaries
The attack surface is every point where an attacker can send data into, or pull data out of, the system. Think of a house where every door and window counts, not just the front door. The medical delivery system has at least:
- The aircraft: flight controller, companion computer, USB and debug ports.
- The links: C2 radio, LTE, and GNSS signals received from space.
- The ground station: control software (GCS) on a laptop, user accounts and stored keys.
- Providers and cloud: the mission server, the UTM service supplier (USS), and patient data tied to parcels.
- The supply chain: firmware, libraries and hardware from manufacturers.
A trust boundary is a line where data crosses from a part we control to a part we cannot trust as much. For every flow across a boundary, ask: “Who sent this? Could it be altered on the way? Who can read it?”
Threat analysis with STRIDE
Shostack (2014) suggests walking through threats by category using STRIDE on a data-flow diagram. Each letter is a violation of one security property.
| Threat | Meaning | Property violated | Example in the delivery system |
|---|---|---|---|
| Spoofing | Pretending to be someone else | Authentication | Forged C2 commands on an unsigned link |
| Tampering | Altering data | Integrity | Changing the mission route on the server |
| Repudiation | Denying an action | Non-repudiation | No log proving who aborted a flight |
| Information disclosure | Data leaks | Confidentiality | Intercepting LTE video and parcel data |
| Denial of service | Making it unusable | Availability | Jamming GNSS or radio on the route |
| Elevation of privilege | Gaining rights | Authorization | Gaining admin rights on the GCS laptop |
Once the threats are listed, score likelihood (L) and impact (I) from 1 to 5 and multiply to get a risk score. This is simple and explainable, but it is an ordinal estimate, not a real probability. Several knowledgeable people should score together and review regularly.
Example 1 Ranking STRIDE threats
Scores are hypothetical values agreed by the team in a threat-modelling meeting.
threats = [
("S", "forged C2 commands on an unsigned link", 3, 5),
("T", "mission route altered on the server", 2, 5),
("R", "no signed log of who aborted a flight", 3, 2),
("I", "LTE video and parcel data intercepted", 3, 4),
("D", "GNSS or radio jamming on the route", 4, 4),
("E", "admin rights gained on the GCS laptop", 2, 5),
]
def level(risk):
return "HIGH" if risk >= 15 else "MEDIUM" if risk >= 8 else "LOW"
for cat, name, like, imp in sorted(threats, key=lambda x: -x[2] * x[3]):
risk = like * imp
print(f"{cat} {name:<40} L{like} x I{imp} = {risk:>2} {level(risk)}")
D GNSS or radio jamming on the route L4 x I4 = 16 HIGH
S forged C2 commands on an unsigned link L3 x I5 = 15 HIGH
I LTE video and parcel data intercepted L3 x I4 = 12 MEDIUM
T mission route altered on the server L2 x I5 = 10 MEDIUM
E admin rights gained on the GCS laptop L2 x I5 = 10 MEDIUM
R no signed log of who aborted a flight L3 x I2 = 6 LOW
Jamming and forged commands are high risk, so they are the first to tackle in Modules 2 and 3. Threats with equal scores (T and E) need further judgement, for example how cheaply and quickly each can be fixed.
Defense in depth
No single control stops everything. Defense in depth stacks controls so an attacker must get through every layer. Anderson (2020) warns that layers only help if they fail independently. If every layer depends on one password or on keys stored on the same machine, an attacker who obtains that gets through all layers at once.
Example 2 Chance that a forged command passes every layer
Values are assumed chances that an attacker passes each layer.
layers = [
("network segmentation of the GCS", 0.30),
("MAVLink 2 signing", 0.05),
("command allowlist and geofence on the aircraft", 0.20),
]
p = 1.0
for name, bypass in layers:
p *= bypass
print(f"+ {name:<48} attack still succeeds with p = {p:.4f}")
print(f"about 1 in {1 / p:,.0f} attempts, if the layers fail independently")
+ network segmentation of the GCS attack still succeeds with p = 0.3000
+ MAVLink 2 signing attack still succeeds with p = 0.0150
+ command allowlist and geofence on the aircraft attack still succeeds with p = 0.0030
about 1 in 333 attempts, if the layers fail independently
If the signing key is stored on the same laptop that was compromised, the second layer does nothing, so the real figure is worse than this product. Separating key storage matters as much as having many layers.
Class activity and lab
Lab: a threat model of the lab system
- Draw a data-flow diagram of the lab drone (SITL or a real aircraft) with its trust boundaries.
- Walk through STRIDE for every flow that crosses a boundary and write at least 10 threats.
- Have three people score L and I independently, compare and agree, then rank them with the code from Example 1.
- Take the top three threats, design layered controls and note which layers depend on the same thing.
- Record everything in the lab notebook. Never test attacks on systems or radio frequencies without authorization.
Common mistakes
Watch out
- Thinking only about the radio link and forgetting the GCS laptop, the cloud and the supply chain.
- Scoring risk alone without real operators involved.
- Treating L × I as a probability.
- Stacking layers that share the same weakness.
- Threat modelling once and never revisiting it when the system changes.
Summary
- The UAS attack surface covers the aircraft, links, ground station, cloud and supply chain.
- STRIDE helps cover all six threat categories on flows that cross trust boundaries.
- L × I scores are for ranking, not probabilities.
- Defense in depth works when the layers fail independently.
Check your understanding
- Which STRIDE category is intercepting LTE video?
- A threat with likelihood 4 and impact 3 gets what score and level under the example’s thresholds?
- Three layers can be bypassed with chances 0.5, 0.1 and 0.1. What is the chance of passing all of them (if independent)?
- What is a trust boundary?
- Why does storing the signing key on a compromised GCS weaken defense in depth?
Answers
- Information disclosure.
- , medium.
- , or 1 in 200.
- A line where data crosses from a part we control to a part we cannot trust as much.
- An attacker who owns that machine gets both network access and the key at once, so the layers are not independent.
Key formulas
| Risk score | |
| Chance of passing every layer (if independent) |
Key references
- AlTawy, R., & Youssef, A. M. (2017). Security, privacy, and safety aspects of civilian drones: A survey. ACM Transactions on Cyber-Physical Systems, 1(2), Article 7, 1–25. link
- Wang, Z., Li, Y., Wu, S., Zhou, Y., Yang, L., Xu, Y., Zhang, T., & Pan, Q. (2023). A survey on cybersecurity attacks and defenses for unmanned aerial systems. Journal of Systems Architecture, 138, 102870. link
- Shostack, A. (2014). Threat modeling: Designing for security. Wiley. link
- National Institute of Standards and Technology. (2024). The NIST cybersecurity framework (CSF) 2.0. link
- Anderson, R. (2020). Security engineering (3rd ed.). Wiley.
Further reading
Study the assigned knowledge units in advance, review media and take the module quiz
In class / field
Intensive lab and field practice recorded in a lab notebook
Learning evidence: Lab notebook signed by the instructor