Reality Check für die Security
Der Smart Meter Security auf den Zahn gefühlt
Glaubt man Professor Dr. Hartmut Pohl von der softScheck GmbH, ist es um die Security vieler smarter Produkte nicht besser bestellt, als um des Kaisers neue Kleider. Beider Fasern sind nur hauchdünn gesponnen. Dagegen hilft ein ganzheitlicher Security-Testing-Prozess.
»Es werden funktionale Tests durchgeführt und wer prüft die Sicherheit bei seinen eigenen Produkten? Wer von Ihnen macht Security Testing? Keiner. Die Anwesenden schließe ich hier alle ein«, goss Professor Dr. Hartmut Pohl Wasser in den Wein der Diskutanten des 3. Energie&Technik Smart Home & Metering Summits, nicht ohne die Zuhörer auf seinen anschließenden Vortrag zu verweisen. Dort erfuhren sie, warum Security wichtig ist, wie man sie implementiert und was passiert, wenn sie ausgehebelt wird.
Deutsche haben es nur sprachlich etwas leichter: Für sie gibt es »Sicherheit« und »Unsicherheit«. Anglo-Amerikaner unterscheiden zusätzlich zwischen »Safety« und »Security«. »Safety« umfasst die »innere« funktionale und technische Sicherheit des Systems, die den Betrieb gewährleistet, die Fehlertoleranz, den Schutz vor Hardwarefehlern, etwa durch Redundanz. Alles Dinge, auf die Flugpassagiere und AKW-Anrainer Wert legen. »Security« meint eher die Sicherheit gegenüber dem »Außen«, bei Informationstechnik den Schutz vor Hackern, Viren, Malware und Datendiebstahl. Man hat es mit einem intelligenten Gegner zu tun, vor dem man sich schützen muss.
Sicherheit, insbesondere ihre »Security«-Komponente, ist kein fertig käufliches Produkt, sondern ein Prozess. Zu ihm gehört bereits die Bestandsaufnahme der Bedrohungssituation und ex post facto, des Tathergangs. Diese versucht die Bundesregierung für alle verpflichtend vorzugeben, doch, so kritisiert Professor Pohl: »Ihre Strategie ist falsch.« Denn: »Sie schlägt im Gesetz vor, dass die Sicherheitsvorfälle von den Unternehmen gemeldet werden sollten. Das ist so, als wenn der Bürger aufgefordert wird, der Polizei die Anzahl von Taschendiebstählen zu melden: Heute keinen in München, gestern in Köln zwei. Davon hat die Polizei nichts. Sie muss wissen: Wo ist es passiert? Wie ist der Taschendiebstahl von statten gegangen? Hat mir jemand die Hose hinten aufgeschnitten? Und was macht die Bundesregierung? Sie will Sicherheitsvorfälle zählen.« Mehr der Beruhigung, als einem wirksamen Schutz, dienten Anforderungen, wie sie die »Technische Richtlinie BSI TR-03109«, bzw. das »Protection Profile for the Gateway of a Smart Metering System« oder die Normenreihe ISO 27.000 vorsehen, die brächten lediglich einen Grundschutz.
Professor Pohl erläuterte in seinem Vortrag, wie stattdessen eine ganzheitliche Sicherheits-Architektur für Smart Meter Gateways aussieht, die auch unentdeckte Schwachstellen in Protokollen, Software und Hardware aufdeckt. »Vorbeugen ist besser als heilen«, lautet die Devise, denn der durchschnittliche Kostenaufwand, kritische Vulnerabilities vor der Freigabe von Produkten zu identifizieren, liegt um ein Vielfaches unter den Kosten, die anfallen, wenn nachträglich Schwachstellen mit Patches und Updates gefixt werden müssen. Fünf Verfahren bilden die Marksteine, die ein ganzheitlicher Security-Testing-Prozess erreichen sollte.
»Security by Design« bezeichnet zunächst das Paradigma integrierter Softwaresicherheit an sich, das den Soft- und Hardwareentwicklungsprozess leiten sollte. Professor Pohls Unternehmen softScheck berät selbst umfassend zu diesem Thema. Der zweite Punkt im Sicherheitskonzept lautet »Threat Modeling«, das Überprüfen der Sicherheitsarchitektur auf Schwachstellen, die sogenannten »Vulnerabilities«. »Assets«, die schützenswerten Komponenten des Systems und deren mögliche Bedrohungen werden hier identifiziert und die Dokumentation und Programmablaufpläne analysiert. Ferner werden umfassende Datenflussdiagramme erstellt, die – beispielsweise bei Smart Meter Gateways - den Datenaustausch mit allen Kommunikationspartnern, von den Haushaltsgeräten über Zähler und Verteiler bis zum Stromlieferanten hin auflisten. »Wir haben mittels Threat Modeling ein Smart Meter Gateway untersucht«, sagt Professor Pohl, »waren an der Entwicklung des Security Designs eines Smart Meter Gateway beteiligt und haben in solchen Projekten durchschnittlich pro Produkt über 100 tatsächlich aus dem Internet ausnutzbare neue Sicherheitslücken identifiziert, die der Hersteller noch nicht kannte.«
In der »Static Source Code Analysis« wird der Source Code einem umfassenden Review unterzogen, der sowohl semantische Probleme, als auch komplexe Fehler wie eine falsche Pointerverwaltung aufdecken kann. Das »Penetration Testing« unterzieht die Software, bzw. das System simulierten Angriffen zur Überprüfung bekannter Sicherheitslücken. Sowohl die Exploits als auch die Fixes für Schwachstellen im Quellcode werden von den softScheck-Fachleuten selbst prorammiert.
Eine dynamischer Robustness-Test, ist das »Fuzzing«, das die ausführbaren Dateien auf noch unbekannte Schwachstellen, die sogenannten »Zero Day Vulnerabilities« überprüft. Im Anwendungsalltag würde der Systembetreiber den Angriff gegen eine unbekannte Sicherheitslücke gar nicht erst bemerken. Von den Programmierern nicht vorgesehene Eingabedaten werden beim Fuzzing dem zu testenden Programm eingespielt, das darauf mit gesteigertem Ressourcenverbrauch oder Crash reagiert. Das (Fehl-)Verhalten des Programmes wird protokolliert und analysiert und gegenüber dem Auftraggeber gegebenenfalls durch einen Exploit nachgewiesen.
»Eine einzige Sicherheitslücke würde beim Smart Meter schon den Zugriff auf das Smart Grid erlauben«, sagt Professor Pohl. »Wir haben mit Threat Modeling in den letzten zehn Projekten im Durchschnitt pro Projekt über 100 neue unbekannte Sicherheitslücken, also Zero Day Vulnerabilities identifiziert. Mit Static Source Code Analysis siebzehn Sicherheitslücken, mit Penetration Testing keine neuen, aber immerhin 76 bereits bekannte und mit Fuzzing 27 Sicherheitslücken. Die Zahlen belegen die Dimension des Problems.«
Als zusätzliche Pfeile im Köcher hält softScheck das »Explorative Testing« und das »Manuelle Code Auditing« bereit, denn zur angemessenen Reaktion auf toolgestützt identifizierte Sicherheitslücken brauchen Programmierer große Erfahrung in Sachen sicherer Programmierung und aktueller Angriffstechniken. Diese sind auch nötig bei der Aufdeckung versteckter, nicht dokumentierter Funktionen in Software und Systemen. Eine solche Backdoor Detection ist besonders für Mobilgeräte wie Smartphones und Tablets sehr sinnvoll.
Was Fuzzing mit Hardware anrichten kann, demonstrierte auf dem Energie&Technik Summit Valerie Mielke von der Firma softScheck. Er attackierte life die Speicherprogrammierbare Steuerung (SPS) eines großen deutschen Herstellers, deren Typ auch Zielobjekt des Wurmes Stuxnet beim Angriff gegen das iranische Atomanreicherungsprogramm war. Angriffspfad Herrn Mielkes war eine das Simple Network Management Protocoll (SNMP) nutzende UDP-Schnittstelle der SPS, die zu Konfigurations- und Supportzwecken über das Internet genutzt wird. Der eingesetzte Fuzzer wurde als Metasploit-Modul implementiert, der Angriff fand auf einem Kali-Linux-System statt.
Durch »Sniffing« kann in SPS mit älteren Versionen des SNMP der zur Identifizierung verschickte sogenannte »Community Name« abgeschöpft werden, mit der der Bediener sich gegenüber der SPS identifiziert und der gleichzeitig bestimmte Schreibrechte auf der SPS beinhaltet. Mittels des »SNMP-Get« Befehls oder einer SNMP-Objekt-ID (OID) kann der Bediener Anfragen an die SPS schicken, die hierauf mit der Preisgabe ihrer Objektinhalte reagiert. Auch bei neueren, sichereren SNMP-Versionen belassen es Hersteller oft bei leicht zu enträtselnden (voreingestellten) Default-Namen mit entsprechenden Schreibrechten. Ist dieser sogenannte »Community Name« bekannt, kann der Bediener durch einen »SNMP-Set«-Befehl die auf der SPS voreingestellten Werte ändern. Durch die mit einem Community Name verbundene Schreibberechtigung kann der Fuzzer (oder der reale Angreifer) die SPS fehlerhaft konfigurieren oder analog zu einem Denial of Service-Angriff so viele Anfragen generieren, dass das System abstürzt.
Valerie Mielke konnte im Live-Angriff den Community Name auf »Private« ändern, was ihm unautorisiert Schreibrechte auf der SPS einräumte und anschließend die SPS mit einem DOS-Angriff erfolgreich attackieren. Wie die verlöschende, mit der SPS verbundene Warnleuchte zeigte, war diese abgestürzt und hätte im echten Leben den von ihr gesteuerten industriellen Prozess angehalten. Wiederbelebung ist in diesem Fall nur durch einen Neustart möglich. Natürlich wäre danach ein weiterer Fernangriff über das Internet möglich, auf den das betroffene Unternehmen wieder den Servicetechniker bemüht, der einen Kaltstart …, ad infinitum.
Legt man Wert darauf, dass den Kunden solche Erlebnisse mit Produkten aus dem eigenen Haus erspart bleiben, lohnt sich eine systematische Planung des Design for Security. Professor Pohl brachte als Partner hierfür sein Unternehmen softScheck ins Spiel: »Wir haben in den letzten zehn Jahren noch keinen Hinweis darauf erhalten, dass wir in einem von uns überprüften Produkt eine Sicherheitslücke oder Backdoor übersehen hätten. Einen erfolgreichen Angriff mussten wir auch noch nicht erleben.« Auf den Publikums-Einwand »Das können Sie doch gar nicht wissen« entgegnete er schmunzelnd: »Das würden uns unsere Auftraggeber, die Produkthersteller schon mitgeteilt haben.«
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
