Sicherheit von Embedded-Systemen
Cybersecurity – die Zeit wird knapp
Es tut sich was in Sachen Cybersecurity: Sowohl auf Bundes- als auch auf europäischer Ebene läuft die Gesetzgebung dazu auf Hochtouren. Höchste Zeit für OEMs und Entwickler von Embedded-Systemen, der Cybersecurity mehr Aufmerksamkeit zu widmen.
Am 1. Mai trat in Deutschland das IT-Sicherheitsgesetz 2.0 in Kraft, während auf europäischer Ebene der »Cyber Resilience Act« (CRA) diskutiert wird und die »Radio Equipment Directive« (RED) ab August 2024 einen Großteil aller Geräte mit Datenfunkverbindung zu höherer Cybersecurity verpflichtet. Das IT-Sicherheitsgesetz und der CRA betreffen die tägliche Arbeit von Entwicklern eingebetteter Systeme nicht direkt, aber der RED gebührt sehr wohl Aufmerksamkeit: Obwohl diese Richtlinie nicht unmittelbar in die nationalen Rechtssysteme der Mitgliedstaaten übernommen wird, legt sie den rechtlichen Rahmen für den Verkauf und die Inbetriebnahme von Funkanlagen in der EU fest. Hersteller der darin erfassten Gerätekategorien müssen bis spätestens 1. August 2024 dafür sorgen, dass die Produkte den Anforderungen entsprechen, bevor sie in der EU auf den Markt kommen. Weil dazu unter anderem die Fähigkeit zu Updates zählt, werden Over-the-Air-Updates (OTA) über Cloudportale praktisch zu einer Voraussetzung für die CE-Kennzeichnung sämtlicher Gerätschaften, die irgendeine Art von Datenfunk nutzen.
An bestehenden Normen orientieren
Schon dieser Aspekt zeigt, dass jeder dem Thema Cybersecurity Priorität einräumen sollte, der Hard- oder Software für Embedded-Systeme entwickelt oder anbietet, die unter die RED fallen. Ein sinnvoller erster Schritt ist dabei, auf Konformität zu den bestehenden Normen wie ETSI EN 303645 (Verbraucherprodukte) oder IEC 62443 (Industrieprodukte) zu achten. Die RED bezieht sich auf diese Normen, die nach Meinung vieler Fachleute die Grundlage für künftige harmonisierte Vorgaben darstellen dürften. Zudem spricht vieles dafür, dass die Endkunden als Betreiber der Geräte die Einhaltung dieser Vorgaben schon wegen der wachsenden Bedrohung durch Hacker-Angriffe verlangen werden.
| OWASP als gemeinnützige Stiftung |
|---|
| Sichere Software auf Rezept? |
|
Das Open Worldwide Application Security Project (OWASP) ist eine gemeinnützige Stiftung, die sich für die Verbesserung der Softwaresicherheit einsetzt. Sie hat eine Top Ten von Risiken erstellt, die unter www.owasp.de auf Deutsch zur Verfügung steht. Die Risiken konsequent zu vermeiden, sollte bereits ein erstes Sicherheitsrezept sein. Das Unternehmen Grossenbacher Systeme gibt zudem fünf Tipps für sichere Embedded-Software: |
Angriffsfläche verringern, Sicherheitsschichten einziehen
Besondere Aufmerksamkeit verdient zudem der risikobasierte Ansatz von IEC 62443. Die Sicherheitsmechanismen dieser Norm bauen wie Schichten aufeinander auf. Wird eine Schicht kompromittiert, so greift die darauffolgende. Ziel des Ansatzes ist die schrittweise Verringerung der Angriffsfläche. Weil sich dies in der Praxis aber nur eingeschränkt umsetzen lässt, ist eine systematische Herangehensweise ratsam. Sie schließt alle Tools, Prozesse und Best Practices zum Schutz der Software und Hardware von Embedded-Geräten ein. Ein sicheres Embedded-System zeichnet sich demnach durch folgende Merkmale aus:
➔ Vertrauenswürdige Laufzeitumgebung (Trusted Execution Environment oder kurz TEE), im Arm-Umfeld auch TrustZone genannt: In einer TEE lassen sich nur speziell dafür freigeschaltete Applikationen ausführen, jedoch beispielsweise keine Hackerprogramme, denen naturgemäß die Freischaltung fehlt.
➔ Partitionierte Hardware-Ressourcen: Trennung von CPU, Cache, Speicher und Schnittstellen, um ihre Funktion möglichst unabhängig und getrennt voneinander bereitzustellen. Dies ermöglicht gegenseitigen Schutz bei Fehlern.
➔ Speichersperrung: Mit der sogenannten Executable Space Protection werden explizit bestimmte Speicherbereiche als nicht rechtmäßig nutzbar gekennzeichnet. Der Missbrauch löst einen Alarm oder Gegenmaßnahmen aus, wodurch ungewollter Code des Hackers keinen Platz findet.
➔ Secure Boot: Jedes Embedded Device bootet ähnlich einem PC und sucht dazu sein kleinstes Startprogramm (Boot), in dem der korrekte Startvorgang inklusive der zu startenden Applikationen sowie deren Reihenfolge festgelegt ist. Eine Manipulation an dieser Stelle ließe den Missbrauch des gesamten Geräts zu. Mit dem Secure-Boot-Feature wird das Boot-Programm mittels kryptografischer Algorithmen bei jedem Start geprüft.
➔ Schutz der gespeicherten Daten (Protect Data at Rest): Dazu gehören Anwendungsdaten, Konfigurationsdaten, Sicherheitsschlüssel, aber auch Usernamen, Userrechte und Kennwörter. Diese sind explizit zu verschlüsseln und sollten in spezieller, im Controller vorhandener Sicherheitshardware geschützt, verschlüsselt und gespeichert werden.
Schwachstellen identifizieren und eliminieren
Hilfreich bei der Entwicklung sicherer Embedded-Systeme ist zudem eine Analyse häufig auftretender Schwachstellen in der Software – hier drängen sich fünf Punkte auf, deren erster besonders kritisch ist:
➔ Buffer Overflow: Pufferüberlaufangriffe treten auf, wenn ein Angreifer Daten oder Code in einen Speicherpuffer schreibt, die Grenzen des Puffers überschreitet und benachbarte Speicheradressen zu überschreiben beginnt. Um Schäden oder eine Übernahme des Systems zu verhindern, darf die Anwendung neue Daten oder neuen ausführbaren Code keinesfalls verarbeiten.
➔ Improper Input Validation: Wenn ein Embedded-System Benutzereingaben erfordert, kann ein böswilliger Benutzer oder Prozess unerwartete Eingaben liefern, die zum Absturz einer Anwendung führen, zu viele Ressourcen verbrauchen, vertrauliche Daten preisgeben oder schädliche Befehle ausführen. Textuelle Eingaben oder Input-Werte dürfen also nur im gültigen oder plausiblen Wertebereich verarbeitet werden.
➔ Improper Authentication: Die Authentifizierung beweist, dass Benutzer oder Prozesse auch jene sind, für die sie sich ausgeben. Eine unsachgemäße Authentifizierung kann es einem Angreifer ermöglichen, die Authentifizierung zu umgehen, wiederholt zu versuchen, ein Passwort zu erraten, gestohlene Zugangsdaten zu verwenden oder ein Passwort mit einem schwachen Passwort-Wiederherstellungsmechanismus zu ändern.
➔ Improper Restriction of Operations within the Bounds of a Memory Buffer: Wenn Programmiersprache oder Betriebssystem es einem Programm ermöglichen, auf unerlaubte Speicherorte zuzugreifen, kann ein Bedrohungsakteur möglicherweise die Kontrolle über das System übernehmen oder es zum Absturz bringen. Jedes Programm darf also nur auf erlaubte Speicherbereiche zugreifen, keines darf Root-Rechte besitzen.
➔ Information Exposure: Sensible Informationen dürfen keinem Bedrohungsakteur zugänglich sein, Kommunikation und Speicherung müssen verschlüsselt erfolgen.
Nur Kompetenz gibt Sicherheit
Obwohl es hinsichtlich der Umsetzung der RED in deutsches Recht weiterhin offene Fragen gibt, liegt eines auf der Hand: Wer sichergehen möchte, dass er Controller oder andere »Funkanlagen« in der Industrie auch nach dem 1. August 2024 mit CE-Zeichen im Europäischen Wirtschaftsraum (EWR) vertreiben kann, sollte darauf achten, dass sie zumindest über eine vertrauenswürdige Ausführungsumgebung (TEE), eine Secure-Boot-Funktion und geschützte Speicherbereiche verfügen. Vorhandene Defizite lassen sich dann unter Umständen auch noch nachträglich durch Updates der Firm- und Software ausgleichen. Deshalb ist es an der Zeit, alte Embedded-Systeme kritisch zu hinterfragen und gegebenenfalls durch neue, RED-kompatible Systeme zu ersetzen. Und bei der Entwicklung solcher Systeme sollten OEMs auf Partner setzen, die Sicherheitsbewusstsein und Kompetenz verbinden.
Grossenbacher Systeme auf der SPS 2023: Halle 7, Stand 480
Der Autor
Jonas Schuster ist Geschäftsleiter Marketing & Vertrieb bei Grossenbacher Systeme.
Lesen Sie mehr zum Thema
