Insbesondere in der Kombination von Cloud-Technologie und IoT braucht es komplexe Sicherheitskonzepte um schutzwürdige Daten von Unternehmen und Kunden auf IoT-Geräten und -Infrastruktur unzugänglich zu machen. Doch es gibt Security-Stopper. Welche, erfahren Sie in dieser Ausgabe der Artikelreihe IoT.
Hätte man vor knapp 20 Jahren einen IT-Security-Architekten befragt, wie man die großen Anzahlen von heterogenen und oftmals örtlich ungebundenen Geräten absichern soll, hätte diese Frage vermutlich eine gewisse Ratlosigkeit ausgelöst. Der Grund hierfür liegt auf der Hand: Während man sich in den vergangenen Jahren langsam, aber stetig vom klassischen Ansatz der Perimeter-Sicherheit gelöst hat, war dieser in den vorhergehenden Dekaden das Mittel der Wahl. Die IT-Architekturen von Unternehmen und Endnutzern ließen sich gleichermaßen problemlos hinter Firewalls positionieren, die sie vom unsicheren Internet ausreichend abschotteten. Der Ansatz war einfach: Alles was sich innerhalb vom Perimeter des internen Netzwerkes befand war vertrauenswürdig, alles außerhalb nicht und musste gesondert geschützt werden.
Eine Reihe von technischen Entwicklungen hat in der jüngeren Vergangenheit dazu geführt, dass dieses Konzept aufgeweicht werden musste. Hierzu zählt allen voran die Cloud-Technologie, die dafür verantwortlich ist, dass die schützenswerten Daten von Unternehmen und Endkunden womöglich überhaupt nicht mehr innerhalb des jeweiligen internen Netzwerkes abgelegt sind, sondern in einem der Rechenzentren großer Cloud-Anbieter. Doch auch das IoT hat hierzu einen entscheidenden Teil beigetragen. Es hat sich gezeigt, dass auch der Absicherung von einzelnen, scheinbar nicht sicherheitskritischen Geräten innerhalb der verschwimmenden Netzwerkgrenzen Aufmerksamkeit geschenkt werden sollte, da diese auffallend häufig von Angreifern als Einfallstore genutzt werden.
Das Kräfteverhältnis zwischen Angreifern und Verteidigern ist sehr einseitig. Während es dem Angreifer genügt, das schwächste Glied in der Kette zu finden, und ein einzelner erfolgreicher Angriff hierauf bereits einen Zugriff zum Zielnetz bieten kann, muss der Verteidiger das Sicherheitsniveau der gesamten Kette im Blick behalten. Dem Angreifer genügt eine einzelne Schwachstelle für den erfolgreichen Angriff, der Verteidiger muss potenziell unzählige verhindern.
In der Folge wurde das Internet of Things in den vergangenen Jahren zum Paradebeispiel für das schwächste Glied. Insbesondere IoT-Botnets nutzen massenweise Schwachstellen in IoT-Geräten aus, um sich stetig zu vergrößern. Dieser Entwicklung widmen wir uns ausführlich im Teil 5 der IoT-Artikelreihe. An dieser Stelle wollen wir zunächst die allgemeine Frage stellen: Was ist der Grund für den teils desolaten Sicherheitszustand von IoT-Geräten?
Der technische Fortschritt schaffte es in atemberaubender Geschwindigkeit, die Miniaturisierung von technischen Geräten voranzutreiben. Durch immer kleinere Fertigungsgrößen im unteren Nanometer-Bereich in der Prozessorherstellung ist es möglich geworden, Chips mit ausreichender Leistung mit minimalem Materialeinsatz zu produzieren. Auch weitere elektrotechnische Bauteile konnten erfolgreich verkleinert werden. Hierzu zählen besonders Antennen, die klassischerweise auf gewisse Mindestlängen in Abhängigkeit der jeweiligen Zielfrequenz angewiesen waren. Die intensive Forschung in diesen Feldern hat es jedoch ermöglicht, auch hier Lösungen für winzige Baugrößen mit überschaubaren Leistungseinbußen zu finden.
Anders sieht es im Bereich der Sicherheitsmaßnahmen aus. Während auf klassischen Desktop- oder Laptop-Computern gewöhnlich Antiviren-Software und Firewall-Lösungen eingesetzt werden, ist dies auf IoT-Geräten meist keine Option. Die Scanning-Routinen der Programme benötigen eine signifikante Menge an Systemressourcen, um das Dateisystem oder ein- und ausgehende Pakete zu untersuchen. Das ist Rechenleistung, die bei einem sparsam designten, auf einen Anwendungsfall zugeschnittenen IoT-Gerät nicht zur Verfügung steht. Außerdem steht die dauerhaft genutzte Rechenleistung direkt im Verhältnis zum verursachten Stromverbrauch. Diese Programme leben von der ständigen Synchronisation mit einer Datenbank, die beispielsweise Virendefinitionen aktualisiert und bekannte Angriffsvektoren beinhaltet. In vielen Fällen sind die IoT-Geräte jedoch nicht dauerhaft mit dem Internet verbunden, um diese aktualisierten Daten anfordern zu können.
Mit der Miniaturisierung schaffte das IoT auch den Durchbruch im Massenmarkt. Es wurde endlich möglich, energiesparsame und kleine Geräte in verschiedensten Anwendungsfällen einzusetzen, sei es von Bastlern oder großen kommerziellen Unternehmen. Eine Tatsache eint jedoch alle Anwender: Eine besondere Attraktivität strahlt das herausragende Preis-Leistungs-Verhältnis der Geräte aus, da sich nun endlich Szenarien mit zahlreichen, vernetzten IoT-Geräten kostengünstig umsetzen lassen. Diese Chance witterten zahlreiche Gerätehersteller, allen voran große chinesische Konzerne die ihre Produkte unter anderem als White-Label-Lösungen auf den internationalen Markt werfen, wo sie unter anderen Herstellernamen an Endkunden verkauft werden. Es entstand ein harter Konkurrenzkampf, der mit geringen Margen [2] und dem Absatz hoher Stückzahlen bestritten wird.
Diese Entwicklung erklärt, warum kostentechnisch im IoT kein Platz für Sicherheit zu sein scheint. Es geht den Herstellern primär darum, Produkte schnell und kostengünstig auf den Markt bringen zu können. Gewinner ist der, der am schnellsten neue Anwendungsfälle erschließt und mit zahlreichen Funktionen punkten kann. An dieser Stelle ist aber auch der Verbraucher mitverantwortlich, der den Hersteller durch seine Kaufentscheidung dazu zwingen könnte, in die Sicherheit der Geräte zu investieren. Solange das nicht geschieht, lohnt es sich für die Hersteller schlicht nicht, zusätzliche Kosten durch eine sichere Softwareentwicklung oder zusätzliche Sicherheitsfunktionen zu verursachen. Das gilt auch für Hardware-Bausteine wie Trusted Platform Modules (TPMs), die durch speziell geschützte Hardware zusätzliche Sicherheitsfunktionen bereitstellen können. Während diese Bausteine in klassischen Computern seit Jahrzehnten auf den Mainboards verbaut werden, erhalten derartige Funktionen, etwa durch Trusted Execution Environments (TEEs) wie ARM TrustZone, [3] erst langsam Einzug und werden aktuell von Entwicklern nur sporadisch genutzt. TEEs sind bislang häufig nur potenteren und teureren IoT-Geräten vorbehalten, die beispielsweise ARM-Prozessoren nutzen. Solange zusätzliche Maßnahmen wie diese nicht von Entwicklern und Nutzern durch ihr Verhalten aktiv eingefordert werden, wählen Hersteller weiterhin stets die günstige und unkomplizierte Variante.
Allgemein steht das IoT für eine nie dagewesene Flexibilität und Dynamik in der Benutzung. Erinnert man sich zurück an den ersten Teil der Artikelreihe, war eine der wichtigsten Botschaften zur Vision des IoT, dass die Geräte sich unscheinbar und unmerklich in den Hintergrund des täglichen Lebens integrieren. Dieser Anspruch birgt jedoch einige technische Herausforderungen, die wir im Folgenden beleuchten.
Zunächst einmal soll die Einrichtung von neuen Geräten möglichst ohne eine lästige Konfiguration durch den Benutzer erfolgen. Man möchte es gerade Privatnutzern ersparen, sich beispielsweise auf der Benutzeroberfläche des eigenen Routers anzumelden, um einzelne Ports für Anwendungen des IoT-Gerätes freizugeben. Solche Prozesse sind mühsam und fehleranfällig. Es ist zudem nicht unwahrscheinlich, dass das Gerät nach den Einstellungen durch den Nutzer nicht einwandfrei funktioniert und Frustration verursacht. Aus diesem Grund haben sich Protokolle wieUniversal Plug and Play (UPnP) [4] etabliert, die es ermöglichen, herstellerübergreifend Geräte in einem IP-Netzwerk anzusteuern und zu konfigurieren. So kann ein neues IoT-Gerät selbstständig Portfreigaben und Weiterleitungen beim Heimrouter anfordern. Dieses Verhalten ist nicht nur deshalb kritisch, weil somit die Router-Konfiguration ohne das Wissen des Nutzers gefährlich abgeändert werden kann. Es existieren weitere Probleme im Umgang mit UPnP: Zusätzlich zu Schwachstellen in UPnP selbst wurden auch bei der Implementierung des Protokolls durch Hersteller zahlreiche Fehler gemacht, die Angreifern vielfältige Einfallstore bieten [5]. Es kann daher an dieser Stelle nur empfohlen werden, die UPnP-Funktion des eigenen Routers gänzlich zu deaktivieren.
Auch nach der ersten Inbetriebnahme bewegen sich die Geräte häufig in einem dynamischen Umfeld. Sei es die Smartwatch, die den ganzen Tag am Körper getragen wird oder der Mähroboter, der sich an den Grundstückgrenzen ohne WLAN-Signal bewegt. Die Geräte nutzen daher viele verschiedene (Übertragungs-)Technologien, Protokolle und Zustandsdaten, um situational awareness – also ein Bewusstsein für die aktuelle Situation – zu generieren. Ist gerade kein Signal der präferierten Übertragungsart verfügbar, wird möglicherweise eine alternative Übertragungsart genutzt, die bekannte Schwachstellen besitzt. Konnten nicht ausreichend Informationen für die aktuelle Situation ermittelt werden, wird ein Fallback-Modus verwendet, der eine eingeschränkte, möglicherweise unsicherere Funktionalität bereitstellt. Solches Wissen ist für Angreifer sehr wertvoll, da sie die zahlreichen Schnittstellen der Geräte durch äußere Einwirkungen in ihrem Sinne beeinflussen können.
Letztlich birgt allein die Bündelung zahlreicher Schnittstellen, Protokolle und Übertragungsarten zusätzliche Risiken. Mit jeder zusätzlichen Schnittstelle, die in einem Gerät implementiert wird, steigt das Risiko, dass Schwachstellen vorhanden sind – sei es im Protokoll selbst oder im Rahmen der Implementierung. IoT-Geräte sind aber auf diese vielen Schnittstellen häufig angewiesen und somit besonders verletzlich für Angriffe. Dass die Geräte zusätzlich nicht nur in einem bekannten und vertrauten Heimnetz-Umfeld betrieben werden, sondern auch unterwegs immer neuen und unbekannten Kommunikationspartnern ausgesetzt sind, verschärft die Situation überdies. Als Ausweg bleibt nur, in der Softwareentwicklung stets die Notwendigkeit neuer Schnittstellen zu hinterfragen, etwaige Debugging-Schnittstellen konsequent zu schließen und bekannt gewordene Sicherheitslücken beharrlich im Auge zu behalten, um sie zeitnah zu beheben.
Im Rahmen dieses Artikels haben wir uns mit den grundlegenden Sicherheitsproblemen von IoT-Geräten befasst und analysiert, woher diese kommen. Im nächsten Teil widmen wir uns erneut dem groß angelegten IoT-Deployment im Regenwald und wagen einen Blick hinter die Kulissen, wie selbst für ein solches, riesiges Sensornetzwerk mit schwachen, energieeffizienten Geräten und ohne externe Infrastruktur ein sicherer Betrieb erreicht werden kann.
[1] Quelle: https://xkcd.com/1966/, Erläuterung vgl. https://www.explainxkcd.com/wiki/index.php/1966:_Smart_Home_Security
[2] vgl. https://www.computerbase.de/2018-08/xiaomi-smartphones-marge-umsatz/
[3] vgl. https://www.arm.com/why-arm/technologies/trustzone-for-cortex-a
[4] vgl. https://de.wikipedia.org/wiki/Universal_Plug_and_Play
[5] vgl. https://www.howtogeek.com/122487/htg-explains-is-upnp-a-security-risk/
Lesen Sie den nächsten Artikel oder kehren Sie zurück zur Gesamtübersicht.
