Cybersicherheit für eingebettete Systeme

Von Medizinprodukten und intelligenten Fahrzeugen bis hin zu Industriecontrollern und Unterhaltungselektronik – eingebettete Systeme sind allgegenwärtig und zunehmend vernetzt. Doch mit der Konnektivität kommt auch die Verwundbarkeit. Eine einzige Sicherheitslücke kann Tür und Tor öffnen für Datenschutzverletzungen, Sicherheitsvorfälle, großflächige Störungen oder sogar behördliche Geldstrafen. Diese eingebetteten Computer steuern häufig kritische Funktionen wie Bremsen, Medikamentenabgabe oder den Zugriff auf private Daten – Funktionen, bei denen eine Kompromittierung zu realen Schäden führen kann. Angesichts dessen ist das Verständnis für Embedded Security nicht mehr optional.

In diesem Artikel erfahren Sie:

 

• Was Cybersicherheit bei eingebetteten Systemen wirklich bedeutet – und warum sie geschäftskritisch wird
• Die wichtigsten Bedrohungstypen: von Malware und Pufferüberläufen bis zu Backdoors in der Lieferkette und physischen Angriffen
• Branchenspezifische Risiken in Bereichen wie Automobil, Gesundheitswesen, industrielles IoT und Unterhaltungselektronik
• Zentrale Gegenmaßnahmen und Best Practices – von Secure Boot und Verschlüsselung bis hin zu Patching und sicherem SDLC
• Wie sich Schwachstellen in Software und Hardware unterscheiden – und wie man sich gegen beide verteidigt
• Welche Vorschriften und Normen die Zukunft der Embedded Security prägen (z. B. ISO 21434, IEC 62443, EU Cyber Resilience Act, FDA-Leitlinien)
• Wie starke Cybersicherheit zu einem Wettbewerbsvorteil werden kann – nicht nur eine Frage der Einhaltung von Vorschriften

Bei Scythe Studio sind wir auf die Entwicklung sicherer Software für eingebettete Systeme spezialisiert. Wenn Sie ein Embedded-Produkt entwickeln, ist jetzt der richtige Zeitpunkt, Sicherheit von Anfang an mitzudenken. Lassen Sie uns darüber sprechen, wie wir Sie unterstützen können.

 

Was ist Cybersicherheit bei eingebetteten Systemen?

Die Sicherheit eingebetteter Systeme ist die Praxis, eingebettete Geräte und deren Software vor unbefugtem Zugriff, Missbrauch und Angriffen zu schützen. Anders ausgedrückt geht es darum, zu verhindern, dass böswillige Akteure auf die spezialisierten Computer in Produkten – von Industriecontrollern bis zu Haushaltsgeräten – zugreifen oder sie kontrollieren. Dieses Fachgebiet umfasst sowohl Software- als auch Hardware-Sicherheitsmaßnahmen.

 

Bedrohungstypen und Angriffsvektoren

Eingebettete Systeme sind einer Vielzahl von Cyberbedrohungen und Angriffsvektoren ausgesetzt. Ein Angriffsvektor ist der Weg oder das Mittel, mit dem ein Angreifer unbefugten Zugriff auf ein Gerät erlangen kann. Im Folgenden geben wir einen Überblick über die wichtigsten Bedrohungskategorien, einschließlich Firmware-/Softwareangriffen, Kommunikationsausnutzung, physischen Angriffen und Risiken in der Lieferkette – jeweils mit Beispielen:

 

Firmware- und Softwareangriffe

Eine wichtige Kategorie betrifft Angriffe auf die Firmware oder die Software, die auf dem eingebetteten Gerät läuft. Da Embedded Software häufig in Low-Level-Sprachen (C/C++) geschrieben ist und auf eingeschränkter Hardware läuft, kann sie Fehler im Speicher-Management oder schwache Schutzmechanismen enthalten – ähnlich wie frühe Computersysteme. Zu den gängigen softwarebasierten Angriffen gehören:

 

• Malware-Injektion: Angreifer bringen das System dazu, schädlichen Code auszuführen, indem sie Softwarelücken ausnutzen oder gefälschte Firmware-Updates bzw. Treiber einschleusen.

 

• Speicherausnutzung (Pufferüberläufe): Viele eingebettete Systeme weisen Schwachstellen wie Pufferüberläufe auf. Hierbei sendet der Angreifer mehr Daten als der Puffer verarbeiten kann, überschreibt Speicher und übernimmt den Programmfluss.

 

• Schwache Authentifizierung oder Anmeldedaten: Falls ein eingebettetes Gerät über eine Management-Schnittstelle verfügt (z. B. ein Web-Admin-Panel oder eine Debug-Konsole), versuchen Angreifer möglicherweise Brute-Force-Angriffe auf Passwörter oder nutzen Standardkennwörter, um Zugang zu erlangen.

 

• Logikfehler in der Software: Eingebettete Anwendungen können Logikfehler oder eine unsachgemäße Eingabeverarbeitung enthalten. Beispielsweise könnte eine unzureichende Eingabevalidierung zu Befehlsinjektion oder Abstürzen führen, wenn unerwartete Daten (wie Sonderzeichen oder ungültige Werte) an die Geräteschnittstellen gesendet werden.

Solche Schwachstellen sind besonders kritisch, wenn sie im Embedded-Betriebssystem oder in häufig wiederverwendeten Softwarekomponenten existieren, da eine Ausnutzung auf dieser Ebene sich auf viele Geräte mit demselben Code auswirken kann.

 

 

Auswirkungen

Erfolgreiche Software-/Firmwareangriffe können Angreifern die Kontrolle über das Gerät oder den Zugriff auf vertrauliche Daten ermöglichen. So kann Malware das Gerät ausspionieren oder sabotieren, während ein Pufferüberlauf dem Angreifer eine Root-Shell verschaffen kann. Da viele dieser Angriffe aus der Ferne erfolgen können (z. B. über ein Netzwerk oder eine Funkverbindung), sind sie besonders gefährlich – ein Hacker könnte tausende Geräte im Internet kompromittieren, wenn diese dieselbe Software-Schwachstelle aufweisen.

Noch beunruhigender ist, dass viele dieser Angriffe allein gegen Softwareschutzmaßnahmen erfolgreich sein können, wenn es keine durch Hardware unterstützte Durchsetzung gibt – weshalb eine mehrschichtige Sicherheitsarchitektur entscheidend ist.

 

Kommunikations- und Netzwerkausnutzung

Kommunikationsprotokolle in eingebetteten Systemen spielen eine entscheidende Rolle beim Datenaustausch zwischen Geräten und Systemen. Diese Protokolle – wie WLAN, Bluetooth, CAN-Bus in Fahrzeugen oder industrielles Ethernet – sind häufig Ziel von Angriffen, da Angreifer versuchen, die übertragenen Daten abzufangen, zu manipulieren oder zu stören:

 

• Man-in-the-Middle (MitM) und Abhören: Angreifer platzieren sich im Netzwerk zwischen dem Gerät und seinem Server oder der Benutzeroberfläche und können so die Kommunikation abfangen und ggf. verändern. Wenn Protokolle nicht verschlüsselt oder authentifiziert sind, kann der Angreifer vertrauliche Daten lesen oder schädliche Befehle einschleusen.

 

• Schwachstellen in Netzwerkprotokollen: Viele eingebettete Systeme nutzen Standard-Internetprotokolle (TCP/IP, HTTP) oder eigene Protokolle. Schwachstellen in deren Implementierung (z. B. wie das Gerät bestimmte Netzwerkpakete verarbeitet) können als Einstiegspunkt dienen.

 

• Denial-of-Service (DoS)-Angriffe: Angreifer können das eingebettete Gerät oder sein Netzwerk mit Verkehr überlasten, um es außer Betrieb zu setzen.

 

• Replay- und Injektionsangriffe: Fehlen kryptografische Schutzmechanismen (z. B. Verschlüsselung oder Nachrichtenauthentifizierung), können Angreifer legitime Nachrichten aufzeichnen und später wiederholen, um unerlaubte Aktionen auszulösen (z. B. ein altes Öffnungskommando an ein Smart Lock senden). Alternativ können manipulierte Nachrichten gesendet werden, um Parserfehler auszunutzen.

 

Auswirkungen

Netzwerkbasierte Angriffe ermöglichen es Angreifern, sensible Daten während der Übertragung zu überwachen oder die Kontrolle über Geräte aus der Ferne zu übernehmen. Beispielsweise könnte ein Angreifer im selben WLAN-Netzwerk Anmeldedaten eines Medizinprodukts ausspähen oder einem Industriecontroller schädliche Befehle senden, um Prozesse zu stören. Daher ist die sichere Kommunikation (Verschlüsselung und Authentifizierung) ein Grundpfeiler der Cybersicherheit eingebetteter Systeme.

Organisationen müssen die potenziellen Sicherheitsrisiken berücksichtigen, die mit unverschlüsselten drahtlosen Schnittstellen und schwach implementierten Protokollen einhergehen – besonders beim Design vernetzter Geräte, die autonom im Feld betrieben werden sollen.

Physische und Hardwareangriffe

Im Gegensatz zu Unternehmensservern, die in Rechenzentren gesichert sind, werden eingebettete Systeme oft in unkontrollierten, öffentlichen oder leicht zugänglichen Umgebungen eingesetzt. Das macht sie anfällig für physische Manipulationen und Angriffe auf niedriger Hardwareebene:

 

• Portzugriff und Missbrauch von Debug-Schnittstellen: Viele Geräte verfügen über Hardware-Debug-Ports (wie JTAG oder UART) oder entnehmbare Speicher. Ein Angreifer mit physischem Zugang kann sich mit diesen Schnittstellen verbinden, um Firmware auszulesen oder Softwareschutzmaßnahmen zu umgehen.

 

• Seitenkanalangriffe (Side-Channel Attacks): Dabei handelt es sich um fortgeschrittene Techniken, bei denen ein Angreifer Geheimnisse (wie kryptografische Schlüssel) extrahiert, indem er Nebenwirkungen der Geräteoperation misst, statt direkt den Algorithmus zu brechen. Stromverbrauchsanalysen sind eine häufige Methode: Durch Messung des Stromverbrauchs während kryptografischer Operationen können Angreifer Schlüssel oder verarbeitete Daten ableiten. Eine weitere Methode ist Timing-Analyse – durch Messen der Ausführungszeit lassen sich Rückschlüsse auf Geheimnisse ziehen. Selbst elektromagnetische (EM) Analysen können abgeleitete Signale erfassen, die mit internen Daten korrelieren. Diese Methoden erfordern meist spezielle Ausrüstung und Nähe zum Gerät, wurden aber erfolgreich gegen z. B. Smartcards und TPM-Chips eingesetzt.

 

• Fehlerinjektion (Glitching): Angreifer können Fehler im Gerät hervorrufen, indem sie die Umgebung manipulieren – etwa durch kurzzeitige Spannungsabsenkung oder das Einspeisen eines plötzlichen Taktimpulses. Diese Fehler können dazu führen, dass das Gerät Anweisungen überspringt oder in unerwünschte Zustände gerät (z. B. das Umgehen einer Authentifizierungsprüfung). Glitch-Angriffe wurden genutzt, um Secure-Boot-Mechanismen auszuhebeln, indem der Bootloader zum Fehlverhalten gebracht wurde.

 

• Physische Manipulation und Diebstahl: Allein der Diebstahl eines Geräts kann zu einer Kompromittierung führen, wenn die darauf gespeicherten Daten nicht geschützt sind.

 

Auswirkungen

Hardwareangriffe sind für Angreifer zwar oft aufwendiger und kostspieliger (erfordern physische Präsenz und Spezialwissen), können jedoch verheerend sein, wenn sie erfolgreich durchgeführt werden. Sie können alle oberen Softwareschichten umgehen – z. B. wenn ein kryptografischer Root-Key per Seitenkanal extrahiert wird, kann der Angreifer anschließend sämtliche Kommunikation entschlüsseln oder das Gerät beliebig imitieren. Viele Hardwareschwachstellen sind zudem nicht patchbar oder nur durch eine neue Hardwareversion zu beheben (eine Schaltung kann man nicht „updaten“ wie Software). Geräte müssen daher mit physischer Sicherheit im Hinterkopf entworfen werden – z. B. mit manipulationssicheren Gehäusen, Sensoren, die Schlüssel bei Öffnung löschen, deaktivierten oder gesperrten Debug-Ports und sicheren Hardwareelementen zur Schlüsselspeicherung.

Im Gegensatz zu Netzwerkbedrohungen zielen diese Angriffe direkt auf das physische Gerät ab und versuchen oft, Schutzmaßnahmen in Hardwarekomponenten wie Secure Bootloadern oder Schlüsselspeichermodulen zu umgehen.

 

Ausnutzung der Lieferkette und Update-Vorgänge

Ein weiterer kritischer Angriffsvektor für eingebettete Systeme ist die Lieferkette – sowohl bei der Komponentenbeschaffung während der Herstellung als auch bei Software-Updates im Lebenszyklus des Produkts. Angreifer können Schwachstellen ausnutzen, bevor das Gerät überhaupt den Endnutzer erreicht:

 

• Kompromittierte Komponenten: Ein unsicherer oder nicht vertrauenswürdiger Zulieferer könnte ein Bauteil (Chip, Modul oder Drittanbieter-Bibliothek) mit versteckter Malware oder Backdoors einführen.

 

• Manipulation von Firmware-Updates: Der Update-Prozess selbst kann missbraucht werden. Wenn es einem Angreifer gelingt, sich als Update-Server auszugeben oder eine Update-Datei (während der Übertragung oder im Speicher) zu manipulieren, kann er schädliche Firmware verbreiten.

 

• Sicherheitslücken in Drittanbieter-Software: Viele eingebettete Systeme beinhalten Open-Source-Komponenten (Betriebssysteme, SSL/TLS-Bibliotheken usw.) oder nutzen Frameworks auf höherer Ebene (z. B. Qt für Benutzeroberflächen). Diese können bekannte Schwachstellen aufweisen. Angreifer durchsuchen oft Firmware-Images nach veralteten Bibliotheken, um bekannte Exploits zu nutzen.

 

• Schwachstellen in Produktion und Provisionierung: Während der Fertigung oder Erstkonfiguration von Geräten können Angreifer oder böswillige Insider bösartigen Code einschleusen oder geheime Schlüssel stehlen, wenn die Prozesse nicht abgesichert sind.

 

Auswirkungen

Angriffe auf die Lieferkette können potenziell zahlreiche Geräte gleichzeitig kompromittieren (z. B. wenn eine Backdoor in eine weit verbreitete Komponente eingebaut oder ein populärer Update-Server gehackt wird). Für einzelne Endnutzer sind solche Angriffe besonders schwer zu erkennen oder abzuwehren, da sie stromaufwärts erfolgen.

Die Sicherheit hängt zudem stark von vertrauenswürdigen Drittkomponenten ab – selbst eine kleine Schwachstelle in einer vom Zulieferer bereitgestellten Bibliothek oder einem Chip kann sich massiv auf die Gesamtsicherheit auswirken. Daher ist ein gutes Lieferanten-Risikomanagement ein wesentlicher Bestandteil der Sicherheitsstrategie.

 

Schwachstellen in Embedded-Software vs. -Hardware

Eingebettete Systeme sind sowohl Software- als auch Hardware-Schwachstellen ausgesetzt, wobei jede Kategorie eigene Eigenschaften, Angriffsmethoden und Herausforderungen bei der Abwehr mit sich bringt. Softwarefehler treten typischerweise häufiger auf und können oft per Update behoben werden, während Hardwareschwächen schwerer zu korrigieren sind und unter Umständen physische Änderungen oder Produktrückrufe erfordern.

Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen:

 

Aspekt	Softwareschwachstellen	Hardwareschwachstellen
Art	Fehler in der Logik, Eingabeverarbeitung oder Konfiguration (z. B. Pufferüberläufe, Authentifizierungsprobleme).	Designfehler in Komponenten oder physischen Schnittstellen (z. B. offene Debug-Ports, schwache Zufallszahlengeneratoren).
Ausnutzungsmethode	Remote-Angriffe über Netzwerkanfragen, Schnittstellen oder Standard-Zugangsdaten.	Erfordert physischen Zugriff oder Spezialwerkzeuge (z. B. Glitching, Seitenkanalangriffe).
Erkennbarkeit	Kann Logs, Abstürze oder Anomalien erzeugen, die durch Softwareüberwachung erkannt werden.	Oft unauffällig; keine Logs, nur physische oder elektrische Nebeneffekte beobachtbar.
Behebbarkeit	Lässt sich meist per Firmware-/Software-Update entschärfen.	In der Regel nicht patchbar; erfordert Hardwareänderung oder physische Gegenmaßnahmen.
Persistenz	Mit passenden Update-Mechanismen über die Zeit behebbar.	Bleibt in allen betroffenen Geräten bestehen, bis sie physisch angepasst werden.
Auswirkung auf Lebenszyklus	Schwachstellen entstehen im Lauf der Zeit, z. B. durch veraltete Software oder auslaufenden Support.	Bestehen während der gesamten Nutzungsdauer des Geräts unverändert weiter.

Die konsequente Trennung vertrauenswürdiger Funktionen in der Hardware sowie die Verwendung von sicherer Schlüsselspeicherung kann Risiken eindämmen, die allein softwareseitig nicht ausreichend kontrollierbar sind.

 

Branchenspezifische Risiken, Prioritäten und regulatorische Rahmenbedingungen

Die Risiken und Prioritäten in der Cybersicherheit eingebetteter Systeme unterscheiden sich erheblich je nach Branche. Eine medizinische Infusionspumpe, ein Steuergerät in einem Auto oder ein intelligenter Thermostat enthalten zwar alle eingebettete Computer, aber die Auswirkungen eines Sicherheitsvorfalls und die Bedrohungslage variieren stark. Im Folgenden betrachten wir vier Schlüsselbranchen – Automobilindustrie, Gesundheitswesen, Industrie/IIoT und Verbraucherelektronik/IoT – und heben deren besondere Anforderungen und Normen hervor.

Branche	Wesentliche Cybersicherheitsrisiken	Sicherheitsmaßnahmen & Entwicklungsprioritäten	Relevante Vorschriften & Normen
Automobilindustrie und Transport	Remote-Angriffe auf Fahrzeugsysteme (z. B. Infotainment, CAN-Bus); Risiko von Kontrollverlust, Diebstahl, Datenschutzverletzungen.	Security by Design; Einhaltung von ISO/SAE 21434 und UNECE WP.29; sichere OTA-Updates; Segmentierung des Fahrzeuginternen Netzwerks; Steuergeräte-Authentifizierung; Bedrohungsüberwachung (Vehicle SOC).	UNECE WP.29 (verpflichtend in EU, UK, Japan); ISO/SAE 21434 (Industriestandard); NHTSA-Richtlinien (USA); Cybersicherheit als Teil der Typzulassung.
Gesundheitswesen und Medizinprodukte	Funkmanipulation von Implantaten (z. B. Herzschrittmacher, Insulinpumpen), Manipulation von Krankenhausgeräten (z. B. Infusionspumpen), Ransomware-Angriffe.	Verschlüsselung/Authentifizierung für Gerätekonnektivität; Segmentierung medizinischer Netzwerke; Sicherheitsmanagement über den gesamten Lebenszyklus nach IEC 62304; Patchfähigkeit; Ausfallsichere Mechanismen.	FDA-Anforderungen für die Marktzulassung (USA); EU-MDR (Europa); IEC 62304, ISO 14971, AAMI TIR57, UL 2900; Änderungen des FD&C Act (2023).
Industrielles IoT und kritische Infrastruktur	Zielgerichtete Angriffe (z. B. Stuxnet), Ransomware, veraltete Protokolle ohne Authentifizierung, IT-OT-Netzwerkkonvergenz. Risiken: physische Schäden und Betriebsunterbrechung.	Defense-in-Depth gemäß IEC 62443; Netzwerksegmentierung (Zonen und Kanäle); starke Zugangskontrollen; sichere Konfigurationen; OT-Monitoring; Patching während Wartungsfenstern.	NERC CIP (Energiesektor USA); IEC 62443-Serie (weit verbreitet); EU NIS-2-Richtlinie (2023); nationale Rahmenwerke (z. B. BSI ICS Security-Kompendium in Deutschland).
Verbraucherelektronik und IoT	Standardpasswörter, fehlende Updates, Datenschutzprobleme (Überwachung), Botnets (z. B. Mirai), laterale Angriffe im Heimnetz über unsichere IoT-Geräte.	Individuelle Zugangsdaten; sicheres Onboarding; OTA-Updates; Verschlüsselung gespeicherter und übertragener Daten; Transparenz für Nutzer; Sicherheitsfunktionen standardmäßig aktiviert.	EU Cyber Resilience Act (CRA, 2024); ETSI EN 303 645; California SB-327 (USA); UK PSTI Act (2022); freiwillige Kennzeichnungen (z. B. IoT-Labeling-Programm Singapur).

 

Gegenmaßnahmen und Best Practices für die Sicherheit eingebetteter Systeme

Die Absicherung eingebetteter Systeme erfordert einen mehrschichtigen Ansatz, der alle Ebenen umfasst – von der Hardware über die Software bis hin zu den Entwicklungs- und Wartungsprozessen des Geräts. Nachfolgend sind wichtige Gegenmaßnahmen und Best Practices aufgeführt, die gemeinsam eine Defense-in-Depth-Strategie für die Embedded-Cybersicherheit bilden:

 

Secure Boot und Vertrauensanker

Eine der grundlegendsten Sicherheitsmaßnahmen ist die Implementierung von Secure Boot, bei der das Gerät beim Start nur verifizierte Firmware ausführt. Secure-Boot-Mechanismen verwenden kryptografische Signaturen zur Überprüfung der Firmware-Integrität in jeder Boot-Phase. Das Gerät enthält einen hardware- oder ROM-basierten Root of Trust (z. B. ein im Silizium eingebrannter öffentlicher Schlüssel), mit dem der Bootloader validiert wird – dieser wiederum prüft die nächste Schicht (z. B. den OS-Kernel) usw. Wurde ein Code manipuliert oder ist er nicht vom Hersteller signiert, wird der Boot-Vorgang abgebrochen und das Ausführen unautorisierter Software verhindert. Secure Boot sollte nach Möglichkeit um Measured Boot oder Attestation ergänzt werden, bei denen kryptografische Hashes der Boot-Komponenten aufgezeichnet und extern überprüft werden können.

 

Hardwarebasierte Sicherheitsfunktionen

Nutzen Sie dedizierte Sicherheitsfunktionen moderner Chips. Viele eingebettete Prozessoren bieten mittlerweile Features wie Trusted Execution Environments (TEE) (z. B. ARM TrustZone), die sensible Codeabschnitte in sichere Bereiche isolieren, auf die normale Anwendungen keinen Zugriff haben. Dadurch können kritische Vorgänge (z. B. Kryptografie, Authentifizierungsroutinen) selbst bei kompromittierter Hauptanwendung geschützt werden. Ebenso können ein Trusted Platform Module (TPM) oder ein Secure-Element-Chip kryptografische Schlüssel sicher speichern und vertrauliche Operationen (z. B. Verschlüsselung, Signierung) isoliert durchführen. Best Practice ist es, private Schlüssel, Gerätezertifikate und andere Anmeldeinformationen in sicherer Hardware abzulegen – sodass ein Angreifer selbst bei erfolgreicher Kompromittierung der Anwendung diese Geheimnisse nicht extrahieren kann. Zudem verfügen viele Chips heute über einen Hardware-Root-of-Trust, der eine starke Identitätsprüfung und Vertrauenskette vom Einschalten an ermöglicht.

 

Starke Kryptografie und Verschlüsselung

Die Auswahl und Implementierung von Verschlüsselungsalgorithmen muss den aktuellen kryptografischen Standards entsprechen. Dadurch lassen sich sensible Daten schützen, Datendiebstahl verhindern und Privatsphäre wahren – selbst bei abgefangener Kommunikation. Idealerweise verfügt jedes Gerät über eine eindeutige Identität (Schlüssel/Zertifikate), um gegenseitige Authentifizierung mit Backend-Diensten oder anderen Geräten zu ermöglichen. Für ruhende Daten (z. B. auf Flash oder Speichern des Geräts) ist Vollverschlüsselung dringend zu empfehlen, insbesondere wenn private Informationen oder Anmeldeinformationen gespeichert werden.

 

Gerätesicherung (Angriffsfläche minimieren)

Eingebettete Geräte sollten in einem „gehärteten“ Zustand ausgeliefert werden, bei dem unnötige Funktionen deaktiviert oder entfernt wurden. Best Practices umfassen: Debug-Schnittstellen im Produktivbetrieb deaktivieren, Test- oder Demo-Code entfernen, Netzwerkzugänge mit Firewalls begrenzen und Standard-Benutzerkonten deaktivieren. Es gilt das Prinzip der minimalen Rechtevergabe – z. B. sollten mehrere Prozesse mit minimalen Berechtigungen laufen und voneinander isoliert sein (z. B. durch Prozessisolation, Container oder Mikro-Kernel-Architektur), damit eine Kompromittierung nicht das gesamte System betrifft. Viele Embedded-Linux-Systeme nutzen heute Mechanismen wie SELinux oder AppArmor, um Richtlinien für den Zugriff von Prozessen durchzusetzen.

Zudem sollten sichere Standardeinstellungen verwendet werden: Benutzer sollten zur Einrichtung starker Passwörter gezwungen werden; Kommunikation sollte standardmäßig verschlüsselt erfolgen (kein Rückfall auf Klartext); das Gerät sollte mit sicheren Konfigurationen ausgeliefert werden. Auch der Speicher und die Schnittstellen sollten gehärtet werden – z. B. durch Aktivierung von Hardware-MPU-/MMU-Funktionen zur Verhinderung von Ausführung in beschreibbarem Speicher (NX-Bit), Einsatz von Stack-Canaries und ASLR zur Erschwerung von Exploits. Trotz vorhandener Ressourcenbeschränkungen haben viele dieser Schutzmaßnahmen nur geringen Einfluss auf die Leistung, erhöhen aber erheblich die Hürde für Angreifer. Weitere Hardening-Maßnahmen können das Sperren von Bootloadern, sichere Speicherung von Geheimnissen oder die Isolierung kritischer Komponenten mittels Mikro-Kernel oder Container umfassen.

Regelmäßige Sicherheitsupdates und Patches

Egal wie gründlich getestet wird – einige Schwachstellen werden erst nach der Markteinführung entdeckt. Daher ist ein robuster Mechanismus für Firmware-Updates unerlässlich. Firmware sollte signiert und authentifiziert sein, und der Update-Kanal durch Transportverschlüsselung gesichert werden. Eine Softwarestückliste (SBOM) sollte alle Komponenten einer Firmware-Version dokumentieren, um Patching und Audits zu erleichtern. Hersteller sollten einen klaren Update-Zeitrahmen definieren und diesen auch den Kunden kommunizieren. Für Endgeräte im Consumer-Bereich ist eine automatische Update-Auslieferung ideal, um sicherzustellen, dass Patches tatsächlich installiert werden. In industriellen oder medizinischen Anwendungen müssen Updates oft geplant erfolgen, um Ausfallzeiten zu vermeiden – aber die Update-Fähigkeit muss gegeben sein. Ein Failsafe-Mechanismus wird empfohlen: zum Beispiel zwei Firmware-Slots, damit das Gerät bei fehlgeschlagenem Update in den letzten bekannten guten Zustand zurückkehren kann (sogenanntes „Bricking“ verhindern).

 

 

Sicherer Entwicklungslebenszyklus (Secure SDLC)

Sicherheit sollte in jede Phase der Entwicklung eingebetteter Systeme integriert sein. Entwickler sollten sichere Programmierpraktiken befolgen und frühzeitig Risikoanalysen durchführen, um Schwachstellen bereits vor der Implementierung zu identifizieren. Ein strukturierter SDLC umfasst Sicherheitsprüfungen in allen Phasen der Softwareentwicklung. Dazu gehört eine Bedrohungsmodellierung bereits zu Projektbeginn, um potenzielle Ziele und Einfallstore für Angreifer zu erkennen und geeignete Schutzmaßnahmen zu definieren. Während der Implementierung sollten Entwickler Richtlinien für sicheres Codieren einhalten (z. B. MISRA C für sicherheitskritische Systeme oder CERT C, um häufige Fehler zu vermeiden). Wo möglich, sollten speichersichere Sprachen für kritische Komponenten eingesetzt werden. Statische Codeanalyse (SAST) kann Pufferüberläufe, unsichere Funktionen und andere Probleme im Quellcode erkennen. Dynamische Tests und Fuzzing sollten auf Geräteschnittstellen angewendet werden. Penetrationstests (ethisches Hacking) am Gerät und dessen Ökosystem (z. B. mobile Apps, Cloud-Dienste) sind dringend zu empfehlen.

 

 

Überwachung und Incident Response

Man sollte davon ausgehen, dass kein System zu 100 % sicher ist. Deshalb ist es wichtig, Mechanismen zur Erkennung und Reaktion auf Angriffe zu integrieren. Hersteller und Anwender sollten über einen Incident-Response-Plan verfügen – z. B. Fähigkeit zur Isolierung eines kompromittierten Geräts (Netzwerktrennung), Analyse von forensischen Daten (sofern verfügbar) und Wiederherstellung (z. B. Re-Flashing der Firmware oder im Extremfall Austausch des Geräts). Wichtig ist auch, genug Rechenleistung und Speicher vorzusehen, um leichtgewichtige Monitoring-Agenten auf ressourcenbeschränkten Geräten zu ermöglichen. Dadurch kann in Echtzeit auf Netzwerkangriffe oder Anomalien reagiert werden.

 

Dokumentation und Schulung

Organisationen, die eingebettete Systeme entwickeln, sollten ihre Sicherheitsanforderungen, Designentscheidungen und Testergebnisse dokumentieren. Das unterstützt nicht nur bei der Einhaltung von Normen, sondern auch die langfristige Wartung – etwa wenn ein neues Team das Produkt übernimmt. Eine umfassende Dokumentation sollte auch mit Sicherheitsstandards für Embedded-Systeme übereinstimmen, um Rückverfolgbarkeit und Prüfbereitschaft über alle fünf Phasen des Sicherheitslebenszyklus sicherzustellen. Investitionen in die Schulung von Entwicklern können künftige Schwachstellen drastisch reduzieren. Auch Endnutzer (soweit sie mit sicherheitsrelevanten Funktionen interagieren) sollten geschult werden, um die Gesamtsicherheit zu erhöhen.

 

Fazit

Cybersicherheit für eingebettete Systeme ist eine vielschichtige Herausforderung, lässt sich aber auf ein einfaches Prinzip zurückführen: das gesamte Gerät als System schützen – mit Blick auf alle potenziellen Angriffswege. Wer das Bedrohungsspektrum versteht – von Softwarefehlern und Netzwerklücken bis zu physischen Angriffen – und gleichzeitig Maßnahmen zur Defense-in-Depth anwendet, kann das Risiko erheblich reduzieren. Die passende Kombination von Schutzmaßnahmen unterscheidet sich je nach Branche (ein Herzschrittmacher priorisiert Sicherheit und Zuverlässigkeit, während ein Konsumgerät eher Datenschutz und Resilienz gegenüber Botnetzen fokussiert), aber die Grundprinzipien eines sicheren Designs gelten überall.

Bei Scythe Studio entwickeln wir sichere, vernetzte Produkte von Grund auf. Wenn Sie an einem eingebetteten System arbeiten, ist jetzt der richtige Zeitpunkt, Cybersicherheit als zentrales Designziel zu betrachten. Ob Automobilindustrie, Gesundheitswesen, industrielles IoT oder Unterhaltungselektronik – wir helfen Ihnen, Sicherheit von Anfang an richtig umzusetzen, regulatorische Anforderungen zu erfüllen und teure Fehler zu vermeiden.

Sprechen wir darüber, wie Ihr Produkt nicht nur funktionsfähig, sondern auch widerstandsfähig wird.