Eine dedizierte CANgineBerry-Firmware macht das Modul zu einem passiven Sicherheits-Monitor für klassische CANopen-Netzwerke. Sie überwacht den Bus auf Datenverkehr, der nicht dem erwarteten Muster entspricht, und meldet jede Anomalie als Ereignis über die serielle Schnittstelle. Der Host, zum Beispiel ein Raspberry Pi, schreibt diese Ereignisse in ein revisionssicheres Protokoll von Sicherheitsvorfällen.
Diese Firmware befindet sich in Vorbereitung und ist demnächst verfügbar.
Da die Erkennung auf dem unabhängigen 32-Bit-Mikrocontroller der CANgineBerry läuft, arbeitet sie mit präzisem Timing und bleibt aktiv, selbst wenn der Host ausgelastet ist oder noch bootet.
Was wird erkannt
Die Firmware lernt das normale Verhalten des Netzwerks oder wird damit konfiguriert und überwacht dann Abweichungen, darunter:
Unerwartete Buslast. Ein plötzlicher oder anhaltender Anstieg der Buslast über das übliche Niveau hinaus kann auf Flooding, einen fehlerhaften Knoten oder eingeschleusten Datenverkehr hindeuten. Dies ist die einzige verfügbare Sicherheitsmaßnahme gegen Denial-of-Service-Angriffe (DoS) auf dem Bus. Sie kann solche Angriffe nicht verhindern, erkennt und meldet sie aber zumindest.
Zeitliche Auffälligkeiten. Viele CANopen-Frames sind periodisch. Wenn eine Nachricht normalerweise alle 100 ms eintrifft und der Abstand zwischen zwei solchen Frames irgendwann kleiner als beispielsweise 60 ms ist, könnte durchaus ein zusätzlicher Frame eingeschleust worden sein. Die Firmware markiert diese zeitliche Auffälligkeit, damit sie untersucht werden kann.
Fehlende oder verspätete Frames. Ein periodischer Frame oder Heartbeat, der ausbleibt oder deutlich später als erwartet eintrifft, kann auf einen Knotenausfall, eine Trennung oder den Versuch hindeuten, ein Gerät verstummen zu lassen.
Unerwartete Identifier. Frames mit CAN-Identifiern, die nicht Teil des konfigurierten Netzwerks sind, deuten auf einen fremden oder unautorisierten Knoten am Bus hin.
Revisionssichere Sicherheitsprotokollierung
Jede erkannte Anomalie wird als strukturiertes Ereignis über den UART gesendet. Auf dem Host können die Ereignisse mit Zeitstempel versehen und in ein nur ergänzbares Protokoll geschrieben werden. So entsteht ein revisionssicherer Nachweis von Sicherheitsereignissen für die Vorfallsanalyse und als Nachweis für moderne Regulierung wie den EU Cyber Resilience Act und IEC 62443.
Erkennung auf dem Modul und Protokollierung auf dem Host bleiben getrennt. Die CANgineBerry beobachtet den Bus und löst Ereignisse aus; der Host entscheidet, wie sie gespeichert, weitergeleitet und behandelt werden.
Haeufig gestellte Fragen
Welche Anomalien erkennt die Firmware?
Unerwartete Buslast, zeitliche Auffälligkeiten (zum Beispiel ein eingeschleuster Frame, der zu kurz nach einer periodischen Nachricht eintrifft), fehlende oder verspätete Frames sowie Frames mit CAN-Identifiern, die nicht Teil des konfigurierten Netzwerks sind.
Kann sie einen Denial-of-Service-Angriff verhindern?
Nein. Die Erkennung unerwarteter Buslast ist die einzige verfügbare Maßnahme gegen Denial-of-Service-Angriffe auf dem Bus. Sie kann den Angriff nicht verhindern, erkennt und meldet ihn aber, sodass Betreiber reagieren können.
Wie werden erkannte Anomalien gemeldet?
Jede Anomalie wird als strukturiertes Ereignis über den UART gesendet. Der Host, zum Beispiel ein Raspberry Pi, versieht die Ereignisse mit Zeitstempel und schreibt sie in ein nur ergänzbares Protokoll, das einen revisionssicheren Nachweis von Sicherheitsereignissen bildet.
Ist die Anomalie-Erkennungs-Firmware schon verfügbar?
Sie befindet sich in Vorbereitung und ist demnächst verfügbar. Sie überträgt den CAN-Dragon-Ansatz zur Anomalie- und Ereignisüberwachung auf klassisches CANopen.