انتقل إلى المحتوى الرئيسي

CPS & IoT Security

AuroraSOC is one of the few SOC platforms that treats Cyber-Physical Systems (CPS) and IoT devices as first-class security assets alongside traditional IT infrastructure. This page explains the unique challenges of CPS security and how AuroraSOC addresses them.

What Are Cyber-Physical Systems?

CPS are systems where software directly controls physical processes:

DomainExamplesRisk
Industrial ControlPLCs, SCADA, DCSPhysical damage to equipment
Building AutomationHVAC, access control, fire suppressionSafety hazards
Medical DevicesInfusion pumps, patient monitorsPatient harm
TransportationTraffic controllers, railway switchesPublic safety
EnergySmart grid, solar inverters, substationsGrid instability

CPS vs. IT Security

Key Differences

AspectIT SecurityCPS/IoT Security
PriorityConfidentiality → Integrity → AvailabilitySafety → Availability → Integrity
PatchingRegular patch cyclesMonths/years between patches (downtime unacceptable)
ProtocolsTCP/IP, HTTP, TLSModbus, DNP3, BACnet, OPC UA, MQTT
DevicesServers, workstationsConstrained (256KB RAM, no screen)
Lifetime3-5 years15-25 years
Isolation responseIsolate and investigateMust maintain safety functions

AuroraSOC's CPS Architecture

Three Firmware Platforms

AuroraSOC supports three distinct firmware platforms, each chosen for specific use cases:

ESP32-S3 — Zephyr RTOS (C)

Use case: Edge AI inference with WiFi connectivity

Why Zephyr + C?

  • TFLite Micro for on-device ML inference (anomaly detection at the edge)
  • Zephyr's hardware abstraction layer supports ESP32-S3's unique peripherals
  • WiFi stack with TLS for secure MQTT communication
  • OTA update capability for remote firmware management

nRF52840 — Embassy-rs (Rust)

Use case: BLE security sentinel and USB device monitor

Why Rust + Embassy?

  • Memory safety without garbage collection on a 256KB RAM device
  • async/await on bare metal for concurrent BLE + MQTT-SN handling
  • Zero-cost abstractions — no runtime overhead compared to C
  • CC310 hardware crypto accelerator for ECDSA attestation

STM32F429 — Ada SPARK (Ada)

Use case: Safety-critical relay control with formal verification

Why Ada SPARK?

  • Formal proof that relay control logic cannot violate safety constraints
  • Pre/Post contracts verified at compile time by the SPARK prover
  • Used in domains where software failures could cause physical harm
  • PKA (Public Key Accelerator) for hardware-accelerated attestation

Firmware Attestation

Every device periodically proves its firmware integrity:

Physical-Cyber Correlation

AuroraSOC's unique capability: detecting attacks that span physical and digital domains.

Correlation Types

TypeDetection MethodExample
PHYSICAL_TAMPERVibration sensor + auth failureSomeone physically accessing a device while attempting digital access
FIRMWARE_MISMATCHHash comparison against known-goodSupply chain attack replacing firmware
ANOMALOUS_TELEMETRYBaseline deviation analysisTemperature spike indicating hardware manipulation
COMMUNICATION_ANOMALYTraffic pattern analysisDevice suddenly communicating with unknown IP
LOCATION_ANOMALYNetwork zone validationDevice appearing in unexpected network segment

How Correlation Works

Critical Alert

Physical-cyber correlation alerts are always treated as Critical severity because they may indicate a sophisticated attacker with physical access to your infrastructure.

CPS Security Tools

The CPS Security agent has six specialized tools:

ToolPurpose
QueryCPSSensorRead real-time telemetry from devices
VerifyAttestationTrigger firmware integrity check
RevokeCertificateRevoke a compromised device's certificate
CorrelatePhysicalCyberRun correlation analysis on events
QueryOTProtocolQuery industrial protocols (Modbus, DNP3, OPC UA)
IsolateNetworkSegmentIsolate an OT network segment (requires approval)