Mit den Digitalisierungsbestrebungen der Unternehmen werden täglich neue Produkte und Services entwickelt. Der neue Digitalisierungsmarkt bietet ein enormes Potential für neue Produkte und Lösungen in den unterschiedlichsten Branchen. Es ist ein Leichtes, günstige Hardware zu kaufen und diese mit einer überall erhältlichen Open Source Applikation zu verheiraten. Da wird ein wenig Linux, MQTT und Raspberry PI zusammengesteckt – und fertig ist das IOT-Produkt, das selbst eingesetzt oder gar verkauft wird. Jedoch, wie sieht das in Sachen Sicherheit aus?
Security by Design

Es ist nun leicht vorstellbar, dass viele dieser neuen Produkte und Geräte direkt mit dem Internet verbunden sind oder gar eine aktive Schnittstelle zwischen internen Netzwerken und dem Internet bilden. Gleichzeitig weiß man, dass es sich beim Anschluss an das öffentliche Internet um einen sensiblen Übergang handelt, an dem nur vertrauenswürdige Geräte genutzt werden sollten. Aber ist dieses Vertrauen gerechtfertigt, wenn die Geräte rein nach Funktionalität gebaut werden – ohne jeglichen Sicherheitsleitfaden und ohne Sicherheits-Framework? Da drängt sich ein Vergleich mit Safety bzw. funktionaler Sicherheit auf. Es ist heutzutage gar nicht mehr vorstellbar, ohne Risikoanalyse der Sicherheitstechnik eine Maschine zu entwickeln. Oder dass die darin verbauten Sicherheitselemente keine entsprechende Zertifizierung haben. Vielmehr geben Standard und Normen vor, wie Sicherheitskomponenten entwickelt und angewendet werden müssen. Für die Informationstechnik gibt es diese Vorgaben zwar noch nicht, aber mit Security by Design sind die Methoden bekannt. Man muss sie jedoch anwenden.

Pentest als Allheilmittel?

Penetrationstests sind ein Mittel zur partiellen Überprüfung des Sicherheitslevels. Damit werden gezielte Angriffe auf Systeme gefahren, um festzustellen, welche Sicherheitslücken vorhanden sind. Es gibt automatisierte und manuelle Tests. Meist werden diese in Kombination durchgeführt. Das ist sicherlich ein sehr guter Weg, um das Niveau festzustellen. Häufig stellt sich jedoch heraus, dass es nicht nur eine Lücke gibt, die man stopfen muss, sondern eine Vielzahl. Wenn man nun anfängt, Pflaster zu kleben, wird es immer ein Kompromiss bleiben. Wenn die Informationssicherheit nicht im Fundament des Geräts verankert ist, wie mit Security by Design, lassen sich die Schwachstellen an der Oberfläche kaum sinnvoll beheben. Trotz alledem sollten Pentests regelmäßig durchgeführt werden – sowohl vom Hersteller der Systeme als auch vom Anwender und Betreiber. Es gibt Dienstleister, welche diese Überprüfung durchführen, aber auch entsprechende Software, mit der man die Tests selber durchführen kann. 

Sicherheit von Anfang an

Per Definition heißt Security by design „Sicherheit von Anfang an“. Diese Aussage wird jedoch unterschiedlich interpretiert. Häufig ist zu lesen, es würde sich ausschließlich um sicheres Softwaredesign handelt. Das ist Auslegungssache. Meiner Meinung nach setzt sichere Software auch bestimmte wichtige Sicherheits-Hardwareelemente voraus. Grundsätzlich geht es bei dem Konzept darum, schon im Designprozess eines Produkts die Informationssicherheit zu berücksichtigen. Das Konzept ist längst bekannt. Viele Hersteller aus dem Safety-Bereich wenden das an, und auch nicht erst seit heute. Ich behaupte sogar, dass die Vorgehensweise aufgrund der Maschinenrichtlinie auch den meisten Maschinenbauern bekannt ist.

Am Anfang steht eine Risikoanalyse. Dieser Ablauf ist den meisten Anwendern aus dem Automatisierungsumfeld bereits ein Begriff. Und sie leben das mit jeder Anlage, die neu designed wird. Man macht sich Gedanken, was soll die Maschine tun und wie wird sie abgesichert. Das ist auch die Basis von Security by Design. Zuerst legt man fest, für welchen Zweck das Produkt eingesetzt wird und welche Funktionen es haben soll.

Security by Design am Beispiel eines Industrie-Routers

Beispielsweise ein Industrierouter für Fernwartung und als Schnittstelle zwischen Office-IT und Produktions-IT. Das alleine reicht natürlich noch nicht als Definition aus. In unserem Fall haben wir genau spezifiziert, welche Dienste und Applikationen auf dem Router verfügbar sein sollen, wie etwa VPN und ein Webserver. Die Risikobetrachtung beginnt bei den Schnittstellen nach außen. Dazu gehören sowohl die Hardwareschnittstellen, wie Ethernet und USB, als auch die Softwareschnittstellen wie das Benutzerinterface oder der Webserver. Jede dieser Schnittstellen wird eigenständig betrachtet und in Anlehnung an die IEC62443 wird eine Mindestanforderung an Sicherheit definiert. Im nächsten Schritt betrachtet man die Motivation bzw. das Ziel eines potentiellen Angreifers – angefangen vom Low-Level Hacker bis hin zu Hackern, die von einer Regierung beauftragt sind, mit viel Budget. Je nachdem, welche Schutzlevel erreicht werden soll, steigen hier natürlich die Anforderungen an die Sicherheit. Ist dieser Teil erfolgreich absolviert, steht das Gerüst der Anforderungen an den Router. Mit Secure Boot, Secure Element und Secure Firmware besteht das Sicherheitskonzept des Routers aus drei Bausteinen.

Secure Boot

Die erste Anforderung ist, ein Secure Boot Konzept zu erstellen. Hier geht es darum, dass sichergestellt ist, dass nur die von uns als Hersteller zertifizierte Software vom Router gestartet werden kann. Gelöst wurde das mit dem sogenannten Trusted Root Chain Prinzip. Basis ist der Vertrauensanker, der in einem Boot-ROM (Ready Only Memory) abgebildet ist und nur einmal während der Produktion in unserem Haus mit unserem Zertifikat und Bootlader beschrieben werden kann. Es kann nur solche Applikationssoftware gestartet werden, die sich über ein entsprechendes Zertifikat ausweist. Selbst wenn ein Angreifer höchsten Systemzugriff auf den Router hat, kann er nie das Zertifikat bzw. dem Bootlader verändern und eine gefälschte Firmware starten. Im zweiten Schritt prüft der Bootlader dann die Firmware im FLASH Speicher gegen das Zertifikat und kann somit feststellen, ob sie wirklich von MB Connect Line signiert wurde. Ist das in Ordnung, startet das Betriebssystem, ansonsten bleibt das System stehen. Eventuelle Manipulationen während des oben beschriebenen Angriffs-Szenarios im laufenden Betrieb sind nie dauerhaft. Nach jedem Neustart des Routers wird die Original-Firmware gestartet. Es ist ein wesentlicher Punkt des Konzepts, dass dem Router keine manipulierte Firmware untergeschoben werden kann. Damit ist es ausgeschlossen, dass ein Angreifer das System dauerhaft übernimmt.

secure boot

Secure Element

Nachdem das System erfolgreich sicher gestartet wurde, benötigt es natürlich auch einen Schreib-/Lese-Speicher. Denn irgendwo müssen die benutzerspezifischen Einstellungen, wie Passwörter und VPN Zertifikate gespeichert werden. Hierzu ist auf dem FLASH ein entsprechender verschlüsselter Bereich angelegt. Das Prinzip kennt bestimmt der eine oder andere Anwender aus dem Office-Bereich, wenn er beim Starten seines PCs schon im BIOS ein Passwort eingeben muss. Hier wird mit dem Passwort die Festplatte entschlüsselt. Falls jemand einen solchen PC findet oder stiehlt, hat er keinen Zugriff auf die Daten der Festplatte. Ähnlich ist das beim Router. Wenn jemand Zugriff auf den Flash-Speicher des Routers bekommt, kann er keine Daten ausles

Es wäre nicht praktikabel, bei jedem Booten des Router sein Passwort einzugeben. Abhilfe schafft hier ein sogenanntes Secure Element. Das ist ein eigener Hardwarebaustein (IC), welcher alle Passwörter, Schlüssel und Zertifikate speichert und nach Prüfung nur mit „Ja“ oder „Nein“ antwortet. D.h. man frägt mit einem gehashtem Passwort an und der Baustein antwortet, ob das richtig ist oder nicht. Der Benutzerspeicher wird in diesem Fall mit einem Schlüssel aus dem Secure Element freigegeben.

 

secure element

Secure Firmware

Als drittes Element kommt die sichere Firmware ins Spiel. Nun, wie kann eine Firmware sicher sein? An dieser Stelle sei erwähnt: Hundertprozentige Sicherheit gibt es nicht, aber man sollte alles Mögliche zur Absicherung tun. Zuerst ist es wichtig, dem Entwickler das notwendige Wissen über eine sichere Softwareentwicklung in die Hand zu geben. Das ist nur mit vielen Workshops und Schulungen erreichbar – und ein Prozess, der nicht von heute auf morgen stattfindet. Als Hersteller von Security-Komponenten und -Lösungen beschäftigen wir uns nun schon seit etlichen Jahren mit dem Thema Sicherheit und rollen das auch stetig bei unseren Entwicklern und allen Mitarbeitern aus. Ein Software-Entwickler im Embedded-Bereich ist auch entsprechend zertifiziert. Das nennt sich T.P.S.S.E und ist ein personenbezogenes Zertifizierungsverfahren für sichere Softwareentwicklung mit 3 jähriger Re-Zertifizierung. Damit ist schon der Grundstein zur sicheren Entwicklung gelegt. Mit diesem Wissen kann in einem klassischen Auswahlverfahren zuerst festgelegt werden, welche Applikationen denn überhaupt in die Firmware eingebunden werden müssen. Konkret geht es um das sogenannte Userland der embedded Linux Umgebung. In der Standard Distribution von Embedded Linux, wird meist zur Hardware mitgeliefert, sind viele Programme implementiert, von denen, je nach Anwendung, auch mal nur 20% genutzt werden. Die restlichen 80% haben keinen Nutzen, stellen aber ein zusätzliches potentielles Einfallstor für Angriffe dar. Unser Userland beinhaltet nur, was tatsächlich gebraucht wird. Im nächsten Schritt ist die jeweilige Implementierung der Applikationen zu prüfen. Beispielsweise, wie die Authentifizierung beim Webserver erfolgt oder wie die Webseiten erstellt werden. Das ist natürlich sehr umfangreich und es sollte jede Applikation im Detail betrachtet und auch die Konfiguration dieser Applikation geprüft werden.

Gerade die Erstellung einer Applikation sollte immer nach dem Motto Security by Default erfolgen. D.h. Sicherheitsfunktionen sollten per Default eingeschaltet sein. Konkret sollte beispielsweise bei einem Webinterface HTTPS anstatt HTTP aktiviert sein. Ebenso sollten keine Standardpasswörter verwendet werden – besser ist es, bei jedem Gerät ein per Zufall generiertes Passwort mitzuliefern.

Patchmanagement

Als letztes Element kommt das sogenannte Patchmanagement. Es soll dafür sorgen, dass auftretende Sicherheitslücken schnell erkannt, geschlossen und der Patch dafür verteilt wird. Open Source Software hat hier den Vorteil, dass diese von vielen genutzt und von der Community regelmäßig gepflegt wird. Je mehr Nutzer, desto schneller werden Schwachstellen erkannt. Wir haben uns für den aktuellsten Linux-Kernel entschieden und haben auch bewusst unsere Anpassungen in den sogenannten Mainline zurückgeführt. Der Idealfall ist natürlich, dass man ein Daily-Build einrichtet, das bedeutet, dass täglich alle verwendeten Applikationen auf Änderungen in der Community geprüft werden. Sollte es eine Änderung geben, wird die sofort in eine neue Firmware eingebunden. Diese Daily-Build ist automatisiert und läuft quasi über Nacht. Danach werden dann automatische Tests mit der Firmware durchgeführt. Am Ende wird die Firmware manuell freigegeben und nicht automatisch. Der Mensch hat hier noch das letzte Wort. Wichtig ist, dass dieser ganze Prozess, bis hin dann zum Deployment (Verbreitung der Firmware) verbindlich festgeschrieben und auch gelebt wird.

Fazit

Entwickler sind vorrangig Experten in ihrer jeweiligen Branche und in ihrem Anwendungsgebiet. Sie haben das Thema Sicherheit in ihrem Entwicklungsprozess seither meist gar nicht oder nur am Rande betrachtet. Das ist kein Vorwurf, sondern nur eine Erkenntnis. Dadurch entstehen aber zwangsläufig Sicherheitslücken in der Software bzw. in den Produkten. Hacker versuchen immer wieder, sich durch diese Lücken erfolgreich Zugang zu den Systemen zu verschaffen. In diesem Beitrag wurde aber auch klar, dass die Automatisierungsbranche schon viel Erfahrung im Umgang mit Richtlinien und deren Anwendung hat – beispielsweise bei Safety, wo es speziell um die Umsetzung anhand einer vorgeschalteten Analyse geht. Das lässt schon mal hoffen. Die geplanten Normen und Standards, wie z.B. IEC62443, haben internationale  Bedeutung und zunehmend Auswirkung auf künftige Geräte und Lösungen. Trotzdem gilt nach wie vor: Security ist kein Produkt, sondern ein Prozess, den man auch leben muss.

Mehr Informationen über den mbNET finden Sie hier.

Autor:

Siegfried Müller, Gründer und Eigentümer von MB Connect Line GmbH

Mitglied im Teletrust Bundesverband IT-Sicherheit und dt. Abgesandter zur ECSO (European Cyber Security Organisation)