Building security into autonomous & robotic systems

As autonomous and robotic devices become embedded in our daily lives, ensuring their security is no longer optional — it’s mission-critical. This talk explores how to build defence-in-depth for these systems, covering controls from OS hardening and cryptographically signed over-the-air updates to embedding security practices throughout the SSDLC.
We’ll share practical strategies for automating key security processes, showing how reducing human involvement can lower the risk of error, and why the right balance between automation and oversight is essential for resilient, secure robotic systems.

Transcript

1. Building Security Protections into Autonomous & Robotic Systems Anastasiia Voitova
2. Anastasiia Voitova Head of Security Engineering @ Cossack Labs Cossack Labs is a security solutions company for mission critical applications, founded in 2014 in UK. Building & breaking secure software/hardware in power grids, fi nance, ML/AI, ICS/SCADA, IIoT, robotic & autonomous systems, communication systems. Since 2022 — helping Ukrainian defenders be more resilient against russian aggression in multiple domains. anastasi@cossacklabs.com linkedin.com/in/anastasiiavoitova/ twitter.com/vixentael
3. ⚠ The content of this presentation is redacted to avoid frustration and regrets. Anastasiia Voitova
4. Our plan 1. Robotic systems architecture. 2. Security goals and security threats. 3. Components of security system (OS hardening, device provisioning, data security, reaction on triggers, cryptographic dynamic trust). 4. Cases and examples. Anastasiia Voitova
5. We will NOT cover 1. Swarm intelligence. 2. Multi domain operations. 3. Security of ML models on devices. Anastasiia Voitova cossacklabs.com/blog/machine-learning-security-ml- model-protection-on-mobile-apps-and-edge-devices/ cossacklabs.com/case-studies/iiot-security-a-hive-and-a-queen/
6. Robotic & autonomous systems are appearing everywhere Anastasiia Voitova
7. Anastasiia Voitova Agriculture Logistics Beehive automation Battle fi eld & recon & evac IIoT use cases * We will not talk about consumer IoT.
8. Robotic system architecture Anastasiia Voitova Device crypto module / TPM sensors SoC WAF data storage apps RF remote controller Base station SIEM PKI RF or internet telemetry, payload, video, commands, OTA internet Core infrastructure IO DMZ Payload processing Telemetry processing Video streams processing Fleet mngmt anomaly detection internet * That’s a very generic scheme to show major components. Every system is unique.
9. Different topologies are possible Anastasiia Voitova Device Base station Core infrastructure Device Base station Core infrastructure Device Device Device Core infrastructure Device Device Base station
10. Security goals Anastasiia Voitova 1. IP protection: protection of payload & telemetry data, data from sensors, ML models, and device fi rmware. 2. Device hijacking and control: protect communication, networking, authenticated access, secure OTA updates. 3. Operator’s security: do not reveal operator’s and home base location. 4. System resilience: protection against reverse engineering and massive exploits (break one device -> break them all).
11. Physical security (direct hardware access, side channels) Supply chain risks (hardware, software) Networking / connection / MitM access Device hijacking / API vulnerabilities (perform unauthorised commands) Lack of fi rmware updates Corrupted / malicious updates Combination of threats for each module & threats for data/command fl ow Anastasiia Voitova Fleet management exploits and control over multiple devices Data breaches and leakage Inadequate AuthN and AuthZ Hardware / software vulnerabilities Cryptographic failures Secret management issues Poor device identi fi cation “Evil twin” Identifying Security Threats
12. OWASP IoT Top10 (2018) Anastasiia Voitova owasp.org/www-project-internet-of-things/
13. Identifying Security Threats: OWASP ISTG Anastasiia Voitova github.com/OWASP/owasp-istg
14. IoT / IIoT security guidelines and standards github.com/OWASP/owasp-istg OWASP ISTG csrc.nist.gov/pubs/sp/800/213/ fi nal NIST SP 800-213 IoT Device Cybersecurity Guidance for the Federal Government Anastasiia Voitova csrc.nist.gov/pubs/sp/800/82/r3/ fi nal NIST SP 800-82 Guide to Operational Technology (OT) Security nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.33.ipd.pdf Product development cybersecurity handbook: Concepts and considerations for IoT product manufacturers
15. IoT / IIoT security guidelines and standards Anastasiia Voitova OWASP ASVS NIST SP 800-53 Security and Privacy Controls for Federal Information Systems and Organizations Cossack Labs Mobile Security Score (extension of OWASP MASVS) OWASP SAMM NIST SP 800-37 Risk Management Framework NIST SP 800-207 Zero Trust Architecture NIST CSF CyberSecurity Framework NIST SP 800-63b Digital Identity Guidelines: Authentication and Authenticator Management FMN Spiral 4 and Spiral 5 instructions and speci fi cations. NATO CIS Security Standards …and many many more NIST SSDF Secure Software Development Framework NIST SP 800-160 Engineering Trustworthy Secure Systems
16. Security components for robotic systems Anastasiia Voitova Hardware protection Physical ports restrictions OS hardening Application security Data security (device, transport, cloud) Communication & network security API security Core infrastructure security Monitoring & anomaly detection Fleet management web security Provisioning pipelines security Code quality Secure packaging Secure updates Emergency wipe Intrusion Detection AuthN, authZ, access control Supply chain & dependency management Backups & recovery Reverse engineering protections * These are only engineering and technical controls, think also about procedures, policies, employee management, etc. And many more :) Think zero trust instead of perimeter security. Security system is more than a combination of controls for each module.
17. Device provisioning IaC everywhere: coded → reproducible. Device Identi fi cation Problem is bigger than it sounds. Generate cryptographic keys in SE, and derive all other keys from root keys. Sign images and updates. Test provisioning scripts, test device con fi guration after successful provisioning, and test for provisioning interruptions. Clean up and remove artefacts generated during provisioning. Anastasiia Voitova
18. Minimise human involvement, isolate humans from critical deployment phases Anastasiia Voitova
19. OS hardening Anastasiia Voitova Remove unneeded packages, and apps, and fi les. Keep minimal. Update packages to the stable version you fi nd appropriate. Latest doesn’t always mean best. Think LTS. Disable or limit root, create separate users. Use full disk encryption, LUKS, SecureBoot. Con fi gure WatchDog to recover from service failures. Improve remote access security, disable SSH, setup VPN. Dream about SELinux because who has time for that.. github.com/CISOfy/lynis github.com/decalage2/awesome-security-hardening
20. Payload security Anastasiia Voitova payload generation encryption per device storage transfer & TLS transfer & TLS decryption re-encryption & storage encryptedPayload encryptedPayload Core infrastructure device payload decryption & usage encryptedPayload payload Encrypt data per each device using unique keys, tie data to device. HPKE. Authenticate device. Transfer data encrypted, and store encrypted on any modules that don’t need it (like base station). Re-encrypt on device, decrypt before usage. base station datatracker.ietf.org/doc/rfc9180/
21. Telemetry security Anastasiia Voitova Telemetry (location, logs, sensor data) from device to core should be protected. We care about con fi dentiality (often) and authenticity (always) of telemetry data. Solutions: encryption (AEAD) and signing using device-speci fi c keys. telemetry processing decryption, validation storage transfer & TLS transfer & TLS encryption, signing, storage encryptedTelemetry encryptedTelemetry Core infrastructure device telemetry generation encryptedTelemetry base station
22. Reverse engineering protections Anastasiia Voitova Code obfuscation and active debug detection techniques. Honeypots and honeytokens, fake ssh, fake APIs, fake apps. Wipe and clean up on emergencies. Partial (SE) or complete (the whole device) self-destruction. Alert the core infrastructure of what’s happening. Physical tamper-evidence. github.com/jaksi/sshesame The goal is to make attacker’s life more complicated, save IP and payload.
23. Protecting telemetry data in state-wide critical infrastructure network Anastasiia Voitova Challenges ✦ Hardware emitting telesignals is a heavily outdated legacy equipment. ✦ Telemetry data signals must be transmitted securely and reliably. ✦ There’s no direct communication link between power distribution stations and central dispatch system. ✦ Security of CNI and power grids has a direct effect on the real life. Solution ✦ Emitter: ARM-based devices that parse telemetry signal data, unify its format to be understood by central SCADA system and encrypt data for further secure processing. ✦ Processor: Acra-based cluster in central TSO datacenter to analyse encrypted data. Results ✦ The solution made telemetry data transmitted securely, instantly available for dispatch system and stored for further analysis. The solution is compatible with SCADA legacy system and compliant with regulatory requirements. cossacklabs.com/case-studies/tso/
24. Cryptographic failures in RF encryption allow stealing robotic devices Results ✦ Abusing RF encryption protocols to perform replay attacks and control robotic devices. ✦ Reverse engineering UVs, breaking into cloud infrastructure, and compromising other active UVs from there. cossacklabs.com/blog/cryptographic-failures-in-rf-encryption/
25. UA Drone ID: dynamic trust in unmanned operations
26. UA Drone ID 1. UA DroneID — a suite of protocols and transport methods (software and hardware modules for UVs and ground stations, cloud processing). 2. UA DroneID protocol provides trustworthy positioning, friend-or-foe and telemetry collection for UV/UAVs. Improves and extends the asymmetric advantage that UV operations create. 3. Identi fi cation, inventory, secure telemetry, con fi rmed missions, operator’s security, supporting different vehicle models. Uni fi ed standard for heterogeneous environment. In future: autonomous swarms, meshes. 4. Actively used on the battle fi eld since 2023. Civilian counterpart is being built. 5. Joint efforts by Cossack Labs, CIDTD UA MOD, UA MDT, NGO Aerorozvidka. Anastasiia Voitova
27. Dynamic cryptographic trust to telemetry 1. A set of cryptographic protocols and key management system. 2. A set of zero-trust security controls assuming both UV and UV Control System (UCS) will get into enemy hand. 3. Interactive cryptographic protocol for friend-or-foe. Anastasiia Voitova You cannot update / upgrade robotic devices often → you build security controls to be adaptive.
28. Dynamic cryptographic trust Anastasiia Voitova Trust points optimistic scenario degradation scenario1 degradation scenario2 signature of UV ✅ ❌ ❌ signature of USC ✅ ✅ ❌ signature of pilot ✅ ✅ ❌ keys of unit-level hub ✅ ❌ ✅ network connection of pilot ✅ ✅ ❌ C4ISR login of pilot ✅ ✅ ❌ Trust to message X is de fi ned dynamically as “Zero trust algorithm” (NIST SP 800-207 3.1.1 / 3.3) around message / origin identity, and changes depending on situation.
29. We build resilience using secure fallback mechanisms and dynamic trust.
30. 2. Build defense-in-depth: follow data fl ows rather than relying on perimeter protection for each module. 3. Minimise human involvement and automate security procedures to reduce chances of mistakes. Anastasiia Voitova Lessons learnt 4. Design security controls so that exploit of one device does not lead to the failure of the whole system. 1. Keep complete attack surface in mind: adversaries will look holistically.
31. Anastasiia Voitova Head of Security Engineering @ Cossack Labs cossacklabs.com anastasi@cossacklabs.com linkedin.com/in/anastasiiavoitova/ twiiter.com/vixentael