- Der hohe Vernetzungsgrad und der gleichzeitige Austausch von unternehmenskritischen Daten über das Internet, bietet Cyber-Kriminellen ein größeres Potential als je zuvor.
- Gerade die fehlende Implementierung von Sicherheitsfunktionen im IoT-Umfeld sorgen dafür, dass eine End-to-End IoT Security vor diesem Hintergrund immer mehr an Bedeutung gewinnt.
- Während Unternehmens-Security eher mit einem Perimeter Ansatz möglich war, ist der Zero-Trust-Ansatz in einer IoT Security-Architektur sinnvoll.
Das klassische IoT-Konzept beginnt auf physischer Ebene mit den Endgeräten/Produkten, die mit spezifischen Sensoren und/oder Aktoren ausgestattet sind. Diese Sensoren ermöglichen das Ausmessen bestimmter Messpunkte bzw. Frequenzen und sammeln Daten. Doch eines der zentralen Themen wie ganzheitliche IoT Security gewährleistet werden kann – also eine End-to-End Security – steckt derzeit noch in den Kinderschuhen und bietet zahlreiche Angriffsflächen, um in Devices, Netzwerke und Infrastrukturen einzudringen.
Eine Ende-zu-Ende IoT-Landschaft von kleinen Sensoren, über lokale Controller mit sehr eingeschränkter Leistung (constrained Controller) und stärkeren Edge Devices wie Linux-basierte Gateways, bis zu einer IoT-Plattform in der Cloud kann so aussehen:
Entlang der ganzen Topologie gibt es verschiedene Gründe, warum IoT Security derzeit nur stiefmütterlich betrachtet wird und Cyberkriminelle oft leichtes Spiel haben, IoT Devices und IoT-Plattformen unter ihre Kontrolle zu bringen.
Ein Grund dafür ist zum einen, dass Produktanbieter versuchen, sei es bei Endgeräten oder ganzen IoT-Plattformen, diese so schnell wie möglich auf den Markt zu bringen, auch wenn diese Software noch lange nicht ausgereift ist – denn auf Grund eines schnellen Innovationszykluses herrscht ein enormer Innovationsdruck im IoT-Umfeld. Ein denkwürdiges Beispiel dafür sind die vielen Hacks der Philips Hue die frühzeitig auf dem Markt war, um hier Marktanteile zu sichern. Zum anderen ist auch die Entwicklung und Implementierung von IoT-Plattformen viel zu selten mit einem Security-Gedanken versehen. Die IoT-Plattformen der Hyperscaler sind zwar inzwischen sehr sensibel und verbieten beispielsweise unverschlüsselte Kommunikation zu IoT Devices. Viele Plattformen von Ende-zu-Ende Produktanbietern basieren aber noch auf selbstgebauten Backends. Diese Plattformen werden typischerweise vom Public-Internet isoliert geschrieben und kommen zu schnell zum Einsatz neben industriellen Kontrollsystemen (SCADA). Wird das Unternehmensnetz durch nur einen infizierten Laptop gehackt, stehen IoT Devices ohne Schutz da und ein Erpresser kann schnell die Industrieproduktion lahmlegen, wie es kürzlich bei der Krauss-Maffei Gruppe passierte.
Auch gibt es nur wenige Auflagen oder Anforderungen die Unternehmen Sicherheitsvorkehrungen vorgeben. Beispielsweise gibt jeder CIO klare Unternehmensvorschriften, dass auf jedem Windows-PC ein Virenscanner installiert sein muss. Jedoch gibt es kaum Vorgaben die beispielsweise die Klartext-Speicherung von Passwörtern auf Edge-Computing Devices verbietet. Ist das Device geklaut, ist auch das Passwort nicht mehr sicher. Schauen wir uns die drei Schichten der IoT Topologie, bestehend aus IoT-Geräten, der Kommunikation und dem IoT-Backend, in Bezug auf Security im Einzelnen genauer an.
Schwachstellen und Sicherheitslücken von IoT-Geräten
Auf Ebene der IoT Devices, die sich im Feld befinden gibt es eine Vielzahl an Werkzeugen und Methoden, mit denen sich IoT-Geräte entdecken und infiltrieren lassen. Über die Suchmaschine “Shodan” zum Beispiel verschaffen sich Cyberkriminelle einen Überblick, welche physischen Geräte mit dem Internet verbunden sind und anhand bestimmter Filter-Abfragen können Cyberkriminelle den gewünschten Gerätetyp anfragen und Schwachstellen ausspähen.
Im nächsten Schritt, nachdem ein anfälliges IoT-Gerät auserkoren wurde, kommen verschiedene Angriffsarten und Angriffsvektoren zum Einsatz, um das ausgespähte Gerät zu infiltrieren. Schon heute gibt es eine Vielzahl an verschiedenen Werkzeugen, mit denen Cyberkriminelle die Schwachstellen attackieren können. Eines dieser Werkzeuge, welches eine enorme Bedrohung für das Internet of Things darstellt, sind Mirai Botnetze. Mirai ist eine Schadsoftware, die dutzende Geräte infiziert und mit dessen Hilfe Botnetze aufgebaut werden. Diese Botnetze sind dafür verantwortlich, dass unter anderem gezielt DDoS Attacken gefahren werden können. Das Schlimme an dieser Bedrohung ist, dass der Quellcode frei für die Öffentlichkeit verfügbar ist, theoretisch kann so jeder ein eigenes IoT-Botnetz aufbauen und betreiben und den Quellcode beliebig umschreiben – ein Grund mehr, warum die Anzahl der Mirai Botnetze in den letzten Jahren rasant gestiegen ist.
Andere Angriffsarten sind weitaus komplexer und benötigen eine hohe Expertise der jeweiligen Hacker. Eine Möglichkeit ist das sogenannte “Reverse-Engineering” von Firmware und Betriebssystemen, wobei maßgeblich der Quellcode zurückgesetzt wird.
So kommen Hacker zum Beispiel bei alltäglichen Geräten wie smarten Toastern, Kühlschränken oder Briefkästen, bei denen eine nicht gerade geringe Zahl an Daten gespeichert ist, an persönlichen Daten, die mittels eines Badges hinterlegt sind. So sind zum Beispiel Kreditkartennummern ein beliebtes Ziel.
Auch Industrieanlagen bei denen ganze Produktionslinien mit IoT-Geräten bestückt sind, von der Leuchte unter der Decke bis zum Fußboden, der mittels Chips dafür sorgt, dass zum Beispiel Gabelstapler automatisiert durch die Hallen fahren, sind beliebte Ziele. Das Netz der potentiellen Angriffe kann man so unendlich weiterspinnen.
Um die Situation angemessen dramatisch zu beschreiben stelle man sich die aktuellen Bedrohungsszenarien für PCs und Smartphones vor, jedoch mit dem Entwicklungsstand der Endpoint-Security-Software von vor 20 Jahren.
Deshalb sind folgende Sicherheitsmaßnahmen zu berücksichtigen, um die IoT Devices abzusichern:
- Mutual-Authentication (Zwei-Faktor-Authentifizierung) für den Zugriff von Menschen auf IoT Devices.
- Produktionsprozess absichern, indem eindeutige IDs und Zertifikate auf die Geräte gebracht werden
- Betrieb eines zentralen Device/Zertifikat-Managements um die Identität und Echtheit aller kommunizierender Devices sicher zu stellen.
- Verschlüsselungsmechanismen bei Device, Gateway und Backend (z.B. Mutual TLS)
- Cloud-Infrastrukturen mit vorgeschalteten API Gateways absichern
- Physischer Schutz bei Geräten, die sich im Feld befinden um Diebstahl der lokalen Daten zu vermeiden
- Security Beauftragte sollte selbst Scanning Tools wie Shodan nutzen
Kommunikations- und Übertragungswege protokoll-seitig schützen
Der Kommunikationssicherheit wird vor dem Hintergrund der steigenden Zahl an vernetzten Geräten immer mehr an Bedeutung zugespielt. Während heute jede sichere Web-Seite auf unsicheres HTTP verzichtet und HTTPS verwendet, werden etablierte IoT-Protokolle wie das weit verbreitet MQTT erst dadurch sicher, dass man sie sozusagen in einen HTTPS-Tunnel einpackt. Der dafür gängige Standard ist TLS 1.2 (Transport Layer Security). Einige IoT Cloud-Backends nehmen bereits nur noch MQTT über TLS an und verweigern sich unsicherer Datenanlieferung vollständig. Innerhalb von Unternehmen ist dies jedoch leider noch üblich. Kommt ein Hacker einmal hinter die Firewall über einen infiltrierten PC, stehen viele Industrieanwendungen vollkommen ungeschützt da.
Typischerweise dreht sich auf der Kommunikationsebene alles um die Kommunikation zwischen Devices zum Gateway und vom Gateway zum Backend. Je nach Topologieform – sei es Stern, Peer-to-Peer, Cluster Tree oder Mesh-Netzwerke – sind durchaus Unterscheidungen vorzunehmen und im Einzelfall abzuwägen. Grundsätzlich geht es darum, dass Vertrauen zwischen den Geräten und dem Backend hergestellt wird – wie und wann Gateways, die sich im Feld befinden mit dem Computer im Rechenzentrum kommunizieren dürfen und wie sichergestellt ist, dass die richtigen Geräte miteinander kommunizieren. Grundsätzlich geht es in allen Fällen darum, dass die Übertragung und somit die transferierten Daten geschützt werden und die Kommunikationsteilnehmer sicher authentifiziert und autorisiert sind. Darüber hinaus sollten Applikationsentwickler sich auch immer die Frage stellen wie proaktives Handeln die Angriffsfläche verringert und welche Modellierungsmöglichkeiten es gibt um Angriffssimulationen aufzuzeigen.
Übliche Angriffsszenarien wie das Man-In-The-Middle Szenario, bei dem ein “legales” Zwischenstück der Kommunikationskette durch einen illegalen “Nachbau” simuliert wird, müssen bereits von der Sicherheitsarchitektur ausgeschlossen werden. Deshalb ist es für Unternehmen wichtig, mit welchen Schutzmechanismen die Kommunikation abgesichert werden kann. Besonders bei drahtlos verbundenen IoT-Geräten gibt es viele Wege in die Cloud (siehe dazu auch der frühere Analyst View). Stellt ein Cyberkrimineller beispielsweise ein LoRa Access-Point mit größerer Feldstärke auf, verbinden sich Geräte schnell mal auf die Fake-Infrastruktur, anstelle auf die richtige. Rasch sind damit Passwörter aus den Anmeldeversuchen der Devices ausspioniert, die dann größten Schaden im echten Backend anrichten können.
Um solche komplexen Infrastrukturen besser beherrschen zu können, wird zunehmend das OSI-Modell als Referenzmodell genutzt und rückt nach Einschätzung von Crisp Research zunehmend, mittels verschiedener Protokolle, als Kommunikations-Standard für das Internet of Things in den Fokus.
Den Sicherheits-Experten der Unternehmen sind folgende Sicherheitsmaßnahmen als Standard noch zusätzlich an die Hand zu geben, um die Kommunikationswege abzusichern:
- Grundsätzlich sollte man alte, unsichere Protokolle ausschalten. Dazu zählen Telnet, FTP, HTTP, die bei vielen Linux-Distributionen noch aktiviert sind.
- Einsatz von TLS (Transport Layer Security) /SSL (Secure Socket Layers)/HTTPS
- Absicherung von RPC (Remote Procedure Call)-Schnittstellen
- Absicherung der Kommunikation zwischen den Servern
- Absicherung der Nachrichten-Kommunikation
- Public Key/Certificate Infrastruktur und ein zentrales Device Management, dass Fake-Devices verhindert und jeweils aktuelle Firmware distribuiert.
Infrastruktur (Backend) als sicherer Ort für Daten
Neben den Devices und der Kommunikationsebene ist bei der Sicherheitsarchitektur eine weitere Ebene zu Betrachten – das Backend. Als eines der geläufigsten Backends werden Public Cloud basierte IaaS-Dienste in Anspruch genommen, die die Rechenleistung und Speicherkapazitäten für IoT-Deployments bereitstellen. Beim Entwurf einer IoT-Plattform ist es vor allem wichtig, dass schon zu Beginn des Entwurfsprozesses und der Anforderungsanalysen an das Thema Sicherheit gedacht wird, indem von Beginn an ein Verständnis entwickelt wird, wie Hacker das eigene System infiltrieren könnten. Zudem sollten erste Penetrationstest beim Prototyping unternommen werden. So kann sichergestellt werden, dass von Anfang an ein geeignetes Sicherheitskonzept auf den Beinen steht. Dabei sollte wie in jeder Cloud die allgemeine Privatsphäre, die Zugangssicherheit und ggf. eine verschlüsselte Speicherung beachtet werden. Orientierung zur Etablierung eines sicheren IoT-Cloud Backends geben drei Maßnahmen:
- Methodik bei der Entwicklung und dem Betrieb
- Softwarekomponenten die zusätzliche Sicherheitsaspekte Implementieren
- Physische Sicherheit
Im Einzelnen empfiehlt Crisp Research
- Security by Design
Security by Design-Denken ist eine Methodik und bei der Entwicklung der Backend-Umgebung unerlässlich. Denn eine einfache Security-Architektur reicht schon lange nicht mehr aus. Vielmehr muss der Security-Ansatz, der sich an alle neuen Anforderungen und Bedingungen anpasst, dynamisch aufgebaut werden und in allen Schichten von Anfang an beachtet werden.
- Certifications & Best Practices
Das STAR (Security, Trust & Assurance Registry) Zertifikat der CSA (Cloud Security Alliance) bietet Cloud-Anbietern ein Zertifikat, welches einer strengen und unabhängigen Bewertung unterzogen wird und an Cloud-Anbieter ausgehändigt wird. Das Zertifikat basiert auf Anforderungen des ISO/IEC 27001 Standards und einer spezifischen Cloud Controls Matrix von CSA. Dabei wird maßgeblich untersucht, wie ausgereift die unternehmenseigenen Prozesse sind und welche Anforderungen noch in Betracht gezogen werden müssen, damit ein optimaler Reifegrad erreicht werden kann. Dieses Zertifikat gibt dementsprechend Anwendern der jeweiligen IoT-Lösung ein besseres Verständnis für das eigene Backend-Sicherheitskonzept.
Zudem wird im Allgemeinen das CSA Zertifikat als Best Practice angesehen, um bestimmte Aufgaben zu erfüllen. Auch können weitere Standards wie zum Beispiel das ISM3, der ISF Standard, Cobit5 und der BSI-IT-Grundschutz Leitfaden als Anleitung für Best Practices dienen.
- Software Assurance Maturity Model als Qualitätsfaktor
Um den Reifegrad der eigenen Anwendung zu identifizieren bietet sich die sogenannte SAMM (Software Assurance Maturity Model) Methodik an. Mit diesem Standard lässt sich genau dieser Reifegrad bestimmen. Dabei werden 4 Kategorien gebildet, die die Kernbereiche einer Anwendung abdecken (Governance, Construction, Verification und Deployment). Darüber hinaus sind je Block drei spezielle Unterkategorien gebildet worden. Das Scoring setzt sich aus einer Excel basierten Metrik zusammen, welches aufzeigt in welchen Handlungsfeldern noch Nachholbedarf ist oder wo schon ein guter Fortschritt zu erkennen ist.
- API Gateway/Security Software
Ein API Gateway ist eine Softwarekomponente und etabliert eine weitere Schutzschicht um die APIs der IoT Cloud und ggf. auch Non-Constrained Controllern. Sie dient in erster Linie dazu die Angriffsoberfläche von Diensten und Systemen zu minimieren. API Gateways werden auch typischerweise vor einen Cloud-Dienst oder ein Enterprise-System geschaltet. Dabei befindet sich das API Gateway zwischen Clients und Diensten, also zwischen Front-End und Back-End und steuert die Anfragen von Clients zu dem richtigen Endpunkt bzw. blockt unerwünschte Zugriffe und leitet diese um. Dabei steuert das API Gateway SSL-Beendigungen, Authentifizierung und Autorisierung und kann DDoS Attacken durch Drosselung (Throttling) bestimmter Anfragen abwehren
- Classification von Threats Stride & Dread
Zudem kann die Methodik des Threats-Modelling mit Dread und Stride zur Analyse der Sicherheit einer Anwendung unterstützen. Mittels dieses Ansatzes können Sicherheitsrisiken identifiziert, klassifiziert, bewertet, verglichen und priorisiert werden. Dieser mathematische Ansatz klassifiziert dementsprechend Risiken und gibt Auskunft darüber, welcher Schaden bei einem Cyberangriff zu erwarten ist.
- Erweiterung des Schutzschildes
Neben der API Gateway Software, welche vor die Backend Infrastruktur gestellt wird, kann das Schutzschild noch um einige weitere Werkzeuge erweitert werden. So sollten in Kombination mit dem API Gateway Firewalls, Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IDP), Web Application Firewalls (WAF) als Erweiterung in Betracht gezogen werden.
- Diebstahlschutz von IoT Devices
Das hört sich recht trivial an, aber der physische Diebstahl von Devices und den darin enthaltenen Daten/Zertifikaten/Passwörtern sollte durch physikalische Maßnahmen verhindert werden. Ggf. sind kleine Geräte so zu verbauen, dass sie beim unerlaubten Entfernen gezielt kaputt gehen.
Conclusio und Ausblick
Auf allen Ebenen innerhalb der IoT Security ist noch einiges zu tun. Schon heute gibt es einige Möglichkeiten Geräte und Systeme sicher zu gestalten – die aber auch genutzt werden müssen! Festzuhalten ist, dass es vor allem darum geht die End-to-End Security vom IoT-Gerät bis hin zu den IoT-Plattformen zu garantieren.
Dabei gibt es zwei verschiedene Ansätze eine End-to-End IoT Security zu erreichen, gar zwei verschiedene “Glaubensarten”. Perimeter vs. Zero Trust führte die vergangenen Jahre immer mehr zum Zwiespalt und zur Glaubensfrage von Security-Experten. Während der Perimeter-Ansatz die Sicherheit am Übergang zwischen einem Unternehmensnetz, DMZ und dem Public-Internet beschreibt und sämtliche Security-Maßnahmen bezeichnet, die diesen Übergang absichern, beschreibt der Zero Trust-Ansatz hingegen, dass sich sogar im eigenen Unternehmensnetzwerk nicht einmal die Server gegenseitig vertrauen und jede Aktion verschlüsselt und sicher authentifiziert werden muss – getreu dem Motto “Kontrolle ist besser als Vertrauen”. Ob die klassische Perimeter-Security-Strategie für die IoT Welt überhaupt funktionieren kann, wird in einer der nächsten Publikationen dargestellt.
Zusammenfassend möchten wir alle Akteure auffordern IoT Security von Anfang an mit zu bedenken, sei es bei Geräten, den Backends oder den Kommunikationswegen. Die Sicherheits-Technologien sind vorhanden, jetzt müssen sie auch genutzt werden.