Cyber-Physical Attack Detection
Objective
Detect adversarial attacks targeting the cyber-physical interface — sensor spoofing, actuator hijacking, command injection, and AI inference manipulation — before they cause physical harm.
Control / requirement
Three-layer anomaly detection: (1) Sensor layer — statistical validation of sensor readings against physical models; flag readings deviating >3σ from model prediction; cross-validate against redundant sensor channels. (2) Actuator layer — monitor command streams for sequences inconsistent with operating context; flag commands outside physically feasible envelope. (3) AI inference layer — apply GAISSF™ D2-CTL-01 (Prompt Injection Detection) equivalent for physical AI inputs; monitor input feature distributions for adversarial perturbation signatures. All detections trigger immediate safe state entry (D9-CTL-02) and incident record with root_cause_category = Adversarial_Attack, root_cause_specific_type = Cyber_Physical_Attack.
Business impact
Undetected cyber-physical attacks can cause physical harm indistinguishable from system failure, defeating all insurance and liability defences. NIS2 Art. 21 mandates cybersecurity risk management for critical infrastructure operators — absence of cyber-physical detection is direct non-compliance with criminal and administrative liability in NIS2 transposition legislation.
Validation approach
Test ID: D9-CTL-04-VTS-001 | Test Type: Hybrid (Hardware-in-the-Loop + Automated) | Harness: pytest tests/d9_physical_ai/test_cyber_physical_attack.py -v # oda3-gaissf-vts (requires GAISSF_HIL_ENDPOINT) | Pass Criteria: detection_rate >= 0.95 for injected adversarial inputs; false_positive_rate <= 0.01; mean_time_to_safe_state_ms <= 200. Test corpus: GPS spoofing sequences; LiDAR adversarial patches; camera adversarial examples; actuator command injection sequences; AI inference adversarial examples. Test must be conducted in actual hardware environment. Auditor re-run: test harness documented with seed values for reproducibility.
Expected evidence
Not separately specified in the available source.
Mapping and source
Not separately specified in the available source.
Implementation guidance
Translate the requirement into system-specific procedures, responsible roles, technical configurations and review conditions. Retain evidence showing both design and operating performance. Where the source provides no separate implementation instruction, do not infer that a single technical mechanism is sufficient.
Assessment considerations
- Confirm scope and applicability.
- Inspect control design and responsible ownership.
- Test representative operation and adverse conditions where appropriate.
- Evaluate evidence provenance, completeness and contradictory evidence.
- Record limitations and notably absent outcomes.