OWASP Cheat Sheet Series: Drone Security Cheat Sheet

# Drone Security Cheat Sheet

## Introduction

Drone security is crucial due to their widespread adoption in industries such as military, construction, and community services. With the increasing use of drone swarms, even minor security lapses can lead to significant risks.

This cheat sheet provides an overview of vulnerable endpoints in drone systems and strategies to mitigate security threats.

---

## Drone System Components

A typical drone architecture consists of three main components:

1. **Unmanned Aircraft (UmA)** – The physical drone itself, including its sensors and onboard systems.
2. **Ground Control Station (GCS)** – The interface used to control and monitor drone operations.
3. **Communication Data-Link (CDL)** – The network connection between the drone and the GCS.

![Drone](https://raw.githubusercontent.com/OWASP/CheatSheetSeries/master/assets/Drone_Security_Cheat_Sheet.png)

The communication between the drone and the GCS is vulnerable to interception and attacks. This will be made evident in the future sections as well. It is important to understand that peripherals attached to drone may be vulnerable too! To explain this, we have made a list of **vulnerable endpoints** below.

---

## Vulnerable Endpoints & Security Risks

### 1. Communication Security

- **Insecure Communication Links** – Data transmitted between the drone and GCS can be intercepted if not properly encrypted. Use standard protocols for encryption of any data being sent over.

- **Spoofing and Replay Attacks** – If the drone uses a GPS module then data spoofing and command replay attacks can also become a reality. Again encrypted data transfer is the best way to go forward. There are many more methods, which have been discussed [here](https://www.okta.com/identity-101/gps-spoofing/)

- **Wi-Fi Weaknesses** – Weak authentication or unprotected channels can allow unauthorized access. This is even possible through simple [microcontrollers like ESP8266](https://github.com/SpacehuhnTech/esp8266_deauther)!

    - Use **802.11w MFP (Management Frame Protection)** to prevent Wi-Fi deauthentication attacks. Don't worry, if your Wi-Fi systems are up-to-date, then this is a default protocol now.

### 2. Authentication & Access Control

Most drone controllers use 2 sets of computers,

1. The main chip that performs the PID control and handles motors

2. An additional SoC (called the **companion computer**) to manage peripherals (like the cameras, LiDARs etc.) and send telemetry data.

Thus, it becomes very important to maintain their security as well. The possible risks in this case are:

- **Companion Computers** – Open ports (e.g., SSH, FTP) can be exploited if not securely configured.

- **User Error and Misconfiguration** – Misconfigured security settings can expose the drone to risks.

### 3. Data Protection

Drones often handle sensitive information (e.g., mission details, sensor logs, or edge AI models) and face a high risk of being lost or captured. Therefore, it's important to protect the onboard data:

- **Storage Encryption** - Ensures data is secure at rest, even if someone gains physical access to the drone while it's powered off. Examples: [LUKS](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening) for block-level encryption, [gocryptfs](https://nuetzlich.net/gocryptfs/) for filesystem in userspace, [age](https://github.com/FiloSottile/age) for file encryption.
- **Sensitive Data in RAM** - Store highly sensitive information (e.g, encryption keys, credentials, intellectual property) in RAM and clear after use. Provide this data before mission start using secure channels.

### 4. Physical Security

If your drone is ever captured or lost, you should ensure that it's not physically possible to steal data from it. This may happen under the following conditions:

- **Insufficient Physical Security** – Unsecured USB ports or exposed hardware can lead to data theft or tampering.

- **Insecure Supply Chain** – Compromised components from suppliers can introduce hidden vulnerabilities.

- **End-of-Life Decommissioning Risks** – Improperly decommissioned drones may retain sensitive data or be repurposed maliciously.

### 5. System Integrity

A drone shares many properties with a classical IoT device when it comes to protecting integrity against unauthorized modifications of firmware, software, or configuration. Without these protections, attackers could inject malicious firmware or modify the control stack, gaining persistent and often invisible access - especially if the device is physically accessible to them (e.g., while it is in storage).

Fortunately, IoT also has a number of security controls for such cases:

- **Secure Boot** – Secure Boot ensures that the drone starts only with trusted software:
    - Every piece of firmware is signed with a cryptographic key. Only signed software is allowed to run.
    - A first-stage bootloader is immutable (in ROM or eFuse-locked code). It verifies signature on the second bootloader.
    - Each component verifies the next component (e.g., second stage bootloader -> kernel -> application).

- **Measured Boot** – Measured Boot takes Secure Boot further by recording what software was loaded at each stage. This allows remote systems (like a fleet manager or ground station) to verify that the drone is running only trusted code. It also allows to authorize actions locally, such as releasing decryption keys only when the device boots properly.

- **Firmware Signing** – Ensures that firmware and configuration updates are signed with cryptographic signatures. Implement rollback protection to prevent attackers from loading older, vulnerable firmware versions. It's also a good idea to encrypt firmware packages, especially if they contain sensitive IP.

### 6. Sensor Security

With drones implementing control logic depending on how close they are to other drones or aerial vehicles, manipulating sensor data can be disastrous!

Attackers can manipulate drone sensors (GPS, cameras, altimeters) to feed incorrect data. Think of this more like how [stuxnet](https://en.wikipedia.org/wiki/Stuxnet) changed the speed of the Uranium centrifuges in Iran while still reporting the speed as normal.

To prevent this, there is new research being developed involving **watermarked signals** whose **entropy** can be used to determine if the sensor values are correct of not. Read more about this method [here](https://ieeexplore.ieee.org/abstract/document/9994719).

### 7. Logging & Monitoring

- **Inadequate Logging and Monitoring** – Without sufficient monitoring, security breaches or operational anomalies may go undetected.

- **Integration Issues** – Some cameras require webserver configurations, and if poorly integrated, these web servers on cameras or telemetry systems may expose vulnerabilities that can be used to gather sensitive information.

To prevent this, ensure that your