Software-Design Grundlagen der Sicherheit bei Embedded-Software
Schutzmaßnahmen auf der Betriebssystem- und Hardwareebene gegen Hackerangriffe sind alles andere als perfekt. Daher müssen Entwickler selbst gegen Schwachstellen der Embedded-Software vorgehen.
Anbieter zum Thema

Ich hatte mich auf eine Reise nach Lodz in Polen vorbereitet, der Stadt, in der meine Eltern als Kinder gelebt hatten. Ich war niemals zuvor dort gewesen.
Ich googelte den Namen der Stadt und stieß sehr schnell auf eine Geschichte, die überraschend und erschreckend war: Ein Schüler hatte eine TV-Fernbedienung so manipuliert, dass er damit die Straßenbahn der Stadt steuern konnte – und die Tram damit in eine riesige Modellbahnanlage verwandelte. Der Jugendliche veränderte mit seinem Infrarot-Spielzeug Weichenstellungen und brachte so einige Züge zum Entgleisen. In einem Fall wurden zwölf Menschen verletzt.
In jüngster Zeit haben Begriffe wie Stuxnet und Duqu Eingang in unseren Wortschatz gefunden. Die Sicherheit eingebetteter Systeme ist unerbittlichen Attacken ausgesetzt, darunter auch sogenannte SCADA-Systeme (Supervisory Contron and Data Acquisition), die Industrieanlagen, Verkehrsnetze oder Kraftwerke überwachen und steuern.
Viele Entwickler eingebetteter Software meinen, dass die Sicherheit der Systeme auf der Ebene des Systems Engineering gehandhabt werden sollte – oder von der Hardware, die die Software enthält. In der Tat kann vieles auf dieser Ebene erledigt werden, so zum Beispiel:
- Sichere Netzwerkprotokolle
- Firewalls
- Datenverschlüsselung
- Authentifizierung von Datenquellen
- Hardware-assistiertes Monitoring des Kontrollflusses
- Und Ähnliches.
Aber diese herkömmlichen Techniken reichen nicht aus. Das wurde beängstigend deutlich bei der letztjährigen Embedded Systems Conference in Boston in einem Vortrag zum Thema „Starke Verschlüsselung und korrektes Design sind nicht genug: Schützen Sie Ihr System vor Angriffen aus Seitenkanälen“ beschrieben. Der Referent skizzierte, wie Messungen des Stromverbrauchs, elektromagnetische Lecks, akustische Emissionen und Zeitmessungen Angreifern Informationen geben können, die dazu benutzt werden können, ein Gerät mit eingebetteter Software anzugreifen.
Klar ist, dass Verteidigungsmaßnahmen auf der System- der Hardwareebene nicht ausreichen. Viele Attacken nützen bekanntlich Schwachstellen in der Anwendungssoftware aus. Solche Lücken in unseren eingebetteten Systemen entstehen während des Designs und der Entwicklung der Software. Da Schutzmaßnahmen auf der System- und Hardwareebene alles andere als perfekt sind, müssen wir eine dritte Verteidigungslinie aufbauen, indem wir gegen Schwachstellen in unserer Anwendungssoftware vorgehen.
Natürlich wird die Verteidigungslinie in unserer Software nicht ganz perfekt sein. Das unmittelbare Ziel bei unserer Arbeit an dieser Verteidigungsstellung ist es, die Angriffsfenster, die in unserer Software existieren, zu reduzieren. Der erste Schritt ist es hier, wie ein Angreifer zu denken. Fragen Sie sich, wie ein Angreifer Ihr System und Ihre Software ausnützen könnte, um darin einzudringen.
Sie könnten dies als eine Bedrohungsanalyse ansehen. Benutzen Sie die Ergebnisse der Analyse dazu, um zu beschreiben, was Ihre Software nicht tun sollte. Sie könnten dies als „Missbrauchsfälle“ bezeichnen. Benutzen Sie diese Fälle, um zu planen, wie Ihre Software Attacken besser widerstehen, aushalten oder sich davon wieder erholen kann.
(ID:33374870)