Softwaredesign Die Grundsätze für ein sicheres Internet der Dinge

Redakteur: Franz Graser

David Kleidermacher, Cheftechnologe von Green Hills Software, warnt davor, Datensicherheit nur als eine Frage der Kryptographie oder der Benutzer-Authentifizierung zu betrachten.

Anbieter zum Thema

Durchblick mit Datenbrille: David Kleidermacher, Cheftechnologe des kalifornischen Softwarehauses Green Hills, erläutert seine Gedanken zu sicherem Systemdesign für das Internet der Dinge.
Durchblick mit Datenbrille: David Kleidermacher, Cheftechnologe des kalifornischen Softwarehauses Green Hills, erläutert seine Gedanken zu sicherem Systemdesign für das Internet der Dinge.
(Bild: Frank Boxler/Messe Nürnberg)

„Ich bin überrascht, wie viele Leute in unserer Industrie glauben, Sicherheit sei in erster Linie eine Sache von Kryptographie oder Benutzerauthentifizierung“, sagt David Kleidermacher in einem Gespräch mit der ELEKTRONIKPRAXIS. „Das betrifft Software-Leute, Hardware-Leute, Systemdesigner oder Leute im Vertrieb und im Marketing. Viele von ihnen haben kein klares Konzept von sicherem Design.“

Ergänzendes zum Thema
Die PHASE-Grundsätze im Überblick

David Kleidermacher, der Cheftechnologe von Green Hills Software, hat fünf PHASE-Prinzipien definiert, die zu sicherer Software im Internet der Dinge beitragen:

  • Minimale Implementierung, z. B. durch Verwendung von Microkernel-Architekturen,
  • Aufteilung des Systems in Komponenten,
  • Principle of Least Privilege: Nicht mehr Berechtigungen als nötig,
  • Sicherer Entwicklungsprozess,
  • Validierung durch unabhängige Experten.

Außerdem rät Kleidermacher dazu, die Zugriffe auf Systemressourcen und die Berechtigungen durch einen Hypervisor regeln zu lassen und Tokenizer zu nutzen, anstatt persönliche Daten unverschlüsselt zu verwenden.

Deswegen plädiert Kleidermacher für Aufklärung. „Man muss die grundlegenden Prinzipien von dem verstehen, was ich PHASE nenne, nämlich Principle of High Assurance Security Engineering. Das bezieht sich auf alle Bereiche: Die Software, die Systeme, die Art, wie man Sicherheitsfragen betrachtet. Mit diesen Prinzipien muss man beginnen. Wenn man das nicht tut, ist man verloren.“

Prinzipien für Sicherheit müssen konsequent gelebt werden

Zu diesen Grundsätzen gehört zum Beispiel das Principle of Least Privilege, das Softwareprozessen oder -modulen lediglich den Zugriff auf die Systemressourcen erlaubt, den sie für ihre Aufgabe benötigen. Weitere solche Prinzipien sind die Minimierung der Komplexität oder die Aufteilung des Softwaresystems in Komponenten. Diese Grundsätze sollen aber nicht nur den Entwicklern klar sein. Kleidermacher fordert, dass diese Prinzipien im ganzen Unternehmen verstanden und vom Vorstandschef abwärts von der gesamten Belegschaft gelebt werden.

„Man muss diese Prinzipien auf alles anwenden, was man tut – darauf, wie man den Quellcode verwaltet und das Netzwerk managt, wie man den Zugang zum Computerraum regelt – und auch auf den Prozess für die Softwareentwicklung.“

Insbesondere die Einteilung in Komponenten sieht Kleidermacher als eines der ganz zentralen Prinzipien an. So habe zum Beispiel ein bekannter Hersteller von Netzwerkkomponenten vor einiger Zeit seine Firmware von einem anderen Echtzeitbetriebssystem auf Integrity von Green Hills umgestellt. Den Firmware-Code – immerhin drei Millionen Codezeilen – habe der Netzwerker aber wie bisher als Ganzes in den Kernel-Space verlegt – also den Bereich, in dem der Betriebssystemkern mit höheren Privilegien läuft. „Dadurch verbessert sich natürlich nichts“, sagt Kleidermacher. „Wir haben sie deshalb dazu ermutigt und gedrängt, die Dinge aufzubrechen oder zumindest in den User-Space zu verschieben.“

Das Aufbrechen von Software in überschaubare Komponenten sei natürlich zeitaufwendig und kostenträchtig, „aber es muss gemacht werden“, insistiert der Green-Hills-Cheftechnologe: „Wir empfehlen, dass genau eine Person für eine Komponente verantwortlich ist.“ Dadurch sei gewährleistet, dass der Code der betreffenden Komponente auch überschaubar bleibe. Kleidermacher weiß, dass eine Softwarekomponente pro Person einen Idealzustand darstellt, aber das andere Extrem sieht er als Horrorvorstellung an: „Wenn 50 Personen an einer Komponente arbeiten, ist keiner verantwortlich. Das kann nicht klappen.“

(ID:42701021)