SDS Cyber-Physical Security
Cyber-physical security in Software-Defined Systems (SDS) focuses on protecting the bridge between software and the physical world. A compromise in vehicles, robots, depots, energy assets, or industrial systems can cause real, physical harm. Security must therefore be designed alongside safety, not bolted on later.
This page outlines core threat categories, trust boundaries, controls, and incident-response patterns shared across Software-Defined Vehicles (SDV), Robotics (SDR), Infrastructure (SDI), Energy (SDE), and Industrial Operations (SDIO).
Cyber-Physical Threat Categories
SDS assets face a mix of IT-like and OT-specific threats. The table below groups major threat types.
| Threat Category | Description | Examples |
|---|---|---|
| Remote compromise | Attacks delivered over networks, often via the internet | Exploiting telematics, cloud APIs, depot controllers, VPN gateways |
| Local and proximity attacks | Attacks requiring physical or RF proximity | Malicious USB, Wi-Fi/Bluetooth exploits, local network access |
| Supply-chain tampering | Compromise of hardware, firmware, or software before deployment | Backdoored firmware, compromised third-party components, insecure images |
| Insider and misuse | Malicious or careless actions by authorized personnel | Misconfiguration, bypassed safety, intentional sabotage |
| Ransomware and disruption | Attacks that deny service or extort operators | Locking depot controllers, plant HMIs, or orchestrators |
Trust Boundaries in SDS
Effective cyber-physical security starts by identifying trust boundaries: where data, control, and responsibility cross between domains or actors.
| Boundary | Description | Security Focus |
|---|---|---|
| External network to site or fleet | Internet or carrier networks into depots, plants, or control rooms | Firewalls, VPNs, API gateways, DDoS protections |
| IT to OT | Enterprise systems into operational networks | Segmentation, data diodes, strict access control and monitoring |
| Cloud or backend to assets | Fleet management and OTA systems into vehicles, robots, or DERs | Mutual authentication, signed commands, rate limiting |
| Safety-critical to non-critical domains | Brake, steering, and protection systems vs infotainment or analytics | Network isolation, one-way flows, strict message validation |
| Engineer / operator access | Human access to consoles, tools, and devices | Strong identity, least privilege, audit logging |
Security Objectives for Cyber-Physical Systems
Cyber-physical security extends classic confidentiality, integrity, and availability (CIA) to include safety, control, and resilience objectives.
| Objective | Description | Examples |
|---|---|---|
| Safety | Prevent harm to people, environment, and equipment | Safe states on fault, independent safety channels, physical interlocks |
| Integrity | Prevent unauthorized changes to code, data, and commands | Signed firmware, authenticated control messages, checksum checks |
| Availability | Maintain acceptable operation under attack or failure | Redundant links, backups, graceful degradation strategies |
| Confidentiality | Protect sensitive operational and personal data | Encrypted telemetry, data minimization, access controls |
| Accountability | Ensure actions can be traced to entities and events | Audit logs, signed changes, incident timelines |
Key Controls and Building Blocks
SDS platforms use a layered set of controls to protect devices, networks, software, and operations.
| Control Area | Control | Purpose |
|---|---|---|
| Device and firmware | Secure boot and hardware root of trust | Ensure only signed, trusted code runs on devices |
| Device and firmware | Firmware signing and verification | Protect against tampered or unauthorized images |
| Network | Segmentation and firewalls | Limit lateral movement and isolate safety-critical domains |
| Network | Encrypted channels with strong authentication | Protect integrity and confidentiality of commands and data |
| Access control | Least-privilege roles and just-in-time access | Restrict capabilities and reduce attack surface from insiders |
| Monitoring | Security and anomaly detection | Detect unusual patterns on CAN, TSN, or OT networks |
| Configuration and OTA | Change control, approvals, and rollback | Prevent unsafe or untested changes from reaching the field |
Safety and Security Interaction
Safety and security must be designed together. Security controls should reinforce, not obstruct, safe behavior.
| Aspect | Security Concern | Safety Interaction |
|---|---|---|
| Safety functions | Spoofed or blocked safety messages | Independent safety channels, authentication, redundant paths |
| Fail-safe states | Adversary triggering safe state at wrong time | Define safe but predictable degradation modes |
| Diagnostics and maintenance | Use of privileged modes to bypass protections | Controlled access, session recording, time-limited privileges |
| Performance optimization | AI or optimization engines overriding safety margins | Hard safety limits enforced below optimization layers |
Domain-Specific Considerations
The same security patterns apply across domains but with different emphasis.
| Domain | Primary Concerns | Examples |
|---|---|---|
| Software-Defined Vehicles (SDV) | Vehicle takeover, remote control, privacy | Telematics hardening, in-vehicle network IDS, secure OTA |
| Software-Defined Robotics (SDR) | Worker safety, robot path manipulation | Safety-rated controls, access separation between programming and operation |
| Software-Defined Infrastructure (SDI) | Depot disruption, charge control tampering | Secure chargers, site segmentation, protection of depot schedulers |
| Software-Defined Energy (SDE) | Grid stability, energy theft, protection misoperation | Secure inverter controls, protection relay hardening, secure DER aggregation |
| Software-Defined Industrial Ops (SDIO) | Production outages, unsafe machine operation | OT network security, secure PLC programming, layered safety systems |
Incident Response and Resilience
SDS security planning must assume that incidents will occur. Response and recovery plans determine how much damage is sustained and how quickly operations can resume.
| Element | Role | Examples |
|---|---|---|
| Detection | Notice anomalies quickly | Alarms on unusual traffic, repeated faults, configuration drift |
| Containment | Limit the spread of an incident | Isolate networks, disable remote access, lock down OTA |
| Eradication and recovery | Remove malicious artifacts and restore operation | Re-image devices from trusted sources, roll back configurations |
| Post-incident learning | Prevent recurrence and strengthen controls | Root-cause analysis, control updates, training and playbook refinement |
Design Questions for Cyber-Physical Security
Security design for SDS should start with a small set of high-value questions that shape architecture and operations.
| Question | Design Impact |
|---|---|
| What is the worst realistic physical outcome of a cyber incident? | Defines safety requirements, segmentation depth, and response plans |
| Which components must be trusted under all circumstances? | Identifies roots of trust, safety-critical devices, and hardening priorities |
| How can you operate safely in a degraded or partially compromised state? | Drives fallback modes, isolation strategies, and manual overrides |
| What evidence will you need after an incident? | Shapes logging, traceability, and forensics capabilities |
| How will you maintain and test your security posture over time? | Requires regular assessments, exercises, and validation as systems evolve |
Cyber-physical security is a continuous practice, not a one-time design step. In SDS, it must align with OTA, central compute, data pipelines, and safety engineering to keep vehicles, robots, depots, energy systems, and industrial sites operating safely and predictably under real-world conditions.