Sicherheit im Internet of Things (IoT)

Das Internet der Dinge ( Internet of Things, IoT) beschreibt im weiteren Sinne das Zusammenspiel und jedwede (automatisierte) Kommunikation von Nicht-dedizierten Computersystemen (d.h. Computersysteme, die unterstützend die Steuerung und Kommunikation von Geräten wahrnehmen, Embedded Systems) ohne weitere menschliche Interaktion (M2M, Machine-to-Machine Kommunikation).

Mit dieser Definition werden weite Teile von Bereichen wie die sogenannte Industrie 4.0 ebenso inkludiert, wie Systeme für Smart-Home-, Smart-City-Steuerungen, aber auch der Verkehrs-Telematik (z.B. car-to-car Kommunikation). Die technischen Grundlagen für diese Kommunikationswege sind grundlegend die selben, implementiert unter Verwendung etablierter Internet-Standards, wie beispielsweise Web-Schnittstellen unter Verwendung des Hypertext Transport Protocols (HTTP).

Doch trotz der zu erwartenden Reife dieser Protokolle und ihrer Implementierungen finden im Bereich der “klassischen” (d.h. H2M, Human-to-Machine) Kommunikation, die die Basis für die Entwicklung des WWW dargestellt hat, ständig neue (und alte) Sicherheitsrisken, wie ein Blick auf die Top 10 der Sicherheitsprobleme im Web [Open Web Application Security Project; OWASP 2014] offenbart.

Im Vergleich zum etablierten WWW ist das IoT (zumindest in der o.a. Ausprägung/Definition) eine relativ neue Entwicklung, die noch vielfach die in anderen Bereichen der im Laufe der Zeit ausgemerzten “Kinderkrankheiten” in sich trägt. Daraus ergeben sich zusätzliche, bei der Implementierung solcher Systeme zu berücksichtigende, Gefahren:

  • Geräte- und Systemvielfalt führt zu Unübersichtlichkeit und fehlenden, verifizierten Standards
  • Kurze Time-to-Market: wenig Zeit für ausführliche (Security-)Tests und Systemverifikation
  • Fehlendes Verständnis für die Gefahren vernetzter Systeme, da die Entwicklerinnen und Entwickler von Embedded Systems diese bislang für abgeschottete, für sicher befundene Umgebungen entwickelten
  • Embedded Software wurde/wird oftmals nicht von Software-Spezialistinnen und Spezialisten, sondern von Fachleuten anderer Gebiete als “Nebentätigkeit” entwickelt
  • Aufgrund der lange Zeit fehlenden Komplexität und des relativ geringen Umfangs der Embedded Software wurde/wird auf verifizierbare Methoden des Software-Engineerings oftmals verzichtet
  • Cloud-Computing trägt zu einem nicht unbedeutenden Teil dazu bei, dass das IoT in den letzten Jahren einen massiven Aufschwung genommen hat. Das Vorhandensein von Cloud-Diensten, die, im weitesten Sinne, die Weiterverabeitung der von den IoT-Devices gelieferten Daten vornehmen, machte die allumfassende Vernetzung für unterschiedlichste Bereiche praktikabel, da die entsprechende Infrastruktur nicht mehr von der/dem jeweiligen einzelnen Anwenderin/Anwender zu tragen ist. Gleichzeitig ist diese Entwicklung aber auch dafür verantwortlich, dass vernetzte Devices nicht nur über lokale Netzwerke, sondern buchstäblich weltweit über das internet erreichber sind (s.u). Die (logisch) zentralisierte Speicherung der IoT-Daten führt nebenbei auch zu massiven Datenschutz-Problemen.

Mögen Angriffe auf den vielzitierten “vernetzten Kühlschrank” oder die “Kaffeemaschine mit IP-Adresse” noch harmlos erscheinen, so sind die Auswirkungen von Attacken auf vernetzte Industrieanlagen (in extremis: Kernkraftwerke) oder autonome Fahrzeuge von höchster Brisanz.

Exemplarisch noch einmal zu den scheinbar harmlosen Beispielen: der Mehrwert des vernetzten Kühlschranks wäre bespielsweise, bei Mangel an bestimmten Lebensmitteln diese automatisch per Internet nachzukaufen. Ein Angriff auf dieses Gerät könnte nun dazu verwendet werden, im Namen des Kühlschrankbesitzers dessen Kreditkarte durch automatische Großeinkäufe zu belasten. Im Falle der vernetzten Kaffeemaschine könnte als Akt des Vandalismus mutwillig die Heizplatte eingeschaltet werden, o.Ä.

Davon ausgehend, dass die zunehmende Vernetzung von Industrieanlagen (Industrie 4.0) miteinander, aber auch mit Logistik-, Verkaufs- und anderen vor- bzw. nachgelagerten Systemen nach den selben Prinzipien wie die o.a. Beispiele erfolgt und auch in diesem Bereich eine "Reifung” hinsichtlich des Übergangs von (ab-)geschlossenen zu offenen, vernetzten Systemen erst nach und nach erfolgen wird, sind (politisch oder wirtschaflich motivierte) Angriffe auf diese Anlagen vermehrt zu erwarten, wobei die Schadensdimensionen nur schwer abschätzbar, jedenfalls aber entsprechend hoch sein würden. Dieselbe Problematik ergibt sich sinngemäß auch beim Übergang von leitungsvermittelter (ISDN, POTS/analog) Telefonie auf IP-only/VoIP Systeme, s. [KIRAS/GoVAS, 2011].

Im Folgenden sollen einige dieser Probleme anhand von in OWASP erfolgten Definitionen näher betrachtet werden (die Auswahl der einzelnen Punkte aus der Liste der von OWASP als die 10 wichtigsten Problemfelder definierten Schwachstellen erfolgte subjektiv, um Hinweise zu bieten, dass es sich dabei grundlegend um Themen, die in anderen Bereichen der Internettechnik schon erschöpfend behandelt wurden, handelt, diese im Kontext des IoT jedoch noch nicht die entsprechende Aufmerksamkeit erfuhren.)

OWASP definiert folgende 10 Punkte als die in diesem Zusammenhang relevantesten [OWASP IoT-2014]:

  • I1 Insecure Web Interface (Unsicheres Webinterface)
  • I2 Insufficient Authentication/Authorization (Unzureichende Authentisierung / Berechtigungssteuerung)
  • I3 Insecure Network Services (Unsichere Netzwerkdienste)
  • I4 Lack of Transport Encryption (Fehlender Transportsicherung)
  • I5 Privacy Concerns (Datenschutzprobleme)
  • I6 Insecure Cloud Interface (Unsichere Cloud-Schnittstellen)
  • I7 Insecure Mobile Interface (Unsichere Mobil-Schnittstellen)
  • I8 Insufficient Security Configurability (Unzureichende Scherheits-Optionen)
  • I9 Insecure Software/Firmware (Unsichere Soft-/Firmware)
  • I10 Poor Physical Security (Unzureichende physische Absicherung)

Ad I1): Es ist davon auszugehen, dass jedes IoT-Device in irgendeiner Form ein Web-Interface bereitstellt. Dieses kann sowohl als Benutzer-Interface (z.B. für Administrationszwecke) als auch als Schnittstelle der M2M Kommunikation dienen. Potentielle Angriffsvektoren umfassen schwache Passwörter, abgehörte Credentials (s.a. I4), oder aber auch Anfälligkeit zu XSS (cross-site scripting) Attacken. Die Schwachstellen sind einfach auszunutzen, und häufig für Angreiferinnen und Angreifer einfach zu erkennen. Die Auswirkungen sind meist sehr ernst, speziell im Fall von Administrationszugängen. [OWASP-IoT I1] Abhilfe bietet in erster Linie, auch für IoT-Projekte die Verwendung bewährter und regelmäßig gewarteter und auditierter Web-Frameworks als Ersatz einfacher, “handgestrickter” Lösungen.

Ad I2): Angriffe gegen Systeme mit unzureichender Authentisierung bzw. Zugriffsteuerung können relativ einfach durch Brute-Force-Attacken unter Verwendung “gängiger” Passwörter, unter Ausnützung fehlerhafter Passwort-Wiederherstellungs-Machanismen (z.B. unzureichende Prüfung/Verifizierung von E-Mail-Adressen, etc.) oder Ausnützung schlecht abgestufter System-Berechtigungen durchgeführt werden. Auch diese Schwachstellen kommen relativ häufig vor und sind (auch für Angreiferinnen und Angreifer) einfach zu erkennen. Die potentielle Schadenswirkung ist ähnlich hoch, wie im Punkt I1. Abhilfe lässt sich durch Einhaltung von im “klassischen” WWW bereits bekannten Regeln für die Verwendung und Administration von Passwörtern, durch die Verwendung von verifizierten Methoden der Passwort-Wiederherstellung und Implementierung feiner abgestufter System-Berechtigungen schaffen [OWASP-IoT-I2].

Ad I3): Angriffe auf Netzwerk-Dienste sind bislang eher selten, die häufigste Variante ist dabei das Ausnützen von Buffer-Overflows in der Soft-/Firmware des IoT-Device über das Netzwerk OWASP-IoT-I3]. Wird unwissentlich durch die oftmalige Verwendung von unsicheren Programmiersprachen bzw. Sprachkonstrukten bei der Programmierung der IoT-Devices gefördert. Auswirkungen können, u.A., Datenverlust, Datenmanipulation, DoS (Denial-of-Service), aber auch der Missbrauch des IoT-Devices als Angriffswerkzeug sein. Abhilfe ist in erster Linie durch konsequentes Vorgehen im Software-Engineering (Einhaltung der Vorgaben zur Entwicklung sicherer Software, z.B. [ISC 2012]) und strikte Einhaltung von Protokolldefinitionen gewährleistet.

Ad I4): Fehlende Transport-Verschlüsselung bedeutet, dass alle über das Netzwerk ausgetauschten Daten einfach ausgespäht werden können (OWASP-IoT-I4). Dies speziell dort, wo die Übertragung über ein nicht-exklusives Übertragungsmedium, v.a. also im Bereich der Drahtlosübertragungstechniken (z.B. WiFi), erfolgt. Sehr oft werden verschiedenste Geräte unter Verwendung einfacher, billiger CPU-/WiFi-Module “IoT-fit” gemacht, d.h. eine bislang nur lokal zugängliche und bedienbare Apparatur wird durch die Einbindung in ein Drahtlos-Netzwerk fernwart- und bedienbar gemacht.

Sehr oft erfolgt diese Einbindung ohne (ausreichende) Transport-Verschlüsselung, sodass sich daraus Datenverluste und -manipulationen, speziell aber (s.a. I1) abgehörte Credentials (und alle daraus resultierenden Probleme) ergeben. Abhilfe ist hier nicht immer einfach, da die Firmware der verwendeten Funkmodule sehr oft proprietär und nicht einsehbar ist, d.h. vor allem mangelhafte Verschlüsselung für die Administratorin oder den Administrator nur schwer zu erkennen ist. Die Verwendung von Modulen, deren Firmware entweder frei (Open-Source) oder zumindest austauschbar ist, bietet hier einen gangbaren Ausweg.

Ein großes, allgemeines Problem bei der Verwendung von Kryptografie im IoT-Umfeld stellen die i.A. relativ beschränkten Ressourcen der IoT-Devices. Die Minimierung des Energieverbrauchs dieser Systeme ist meistens ein inheräntes Design-Ziel, das mit Reduktion der CPU-Leistung und möglichst geringer (Arbeits-) Speicher-Ausstattung (Speziell der Refresh von DRAM-Zellen verbraucht einen nicht unbeträchtlichen Anteil der Gesamtenergie) einhergeht. Umgekehrt benötigen effizient eingesetzte Verschlüsselungsalgorithmen nicht unbeträchtliche CPU- und Speicher-Ressourcen. Abhilfe kann hierbei die Verwendung spezieller, auf geringen Ressourcenbedarf optimierter, Krypto-Bibliotheken (z.B. Mbed TLS (vormals Polar SSL, [Mbed TLS]) anstelle von OpenSSL) bieten, aber auch die Verwendung optimierter kryptografischer Verfahren, beispielsweise auf Elliptic Curve Cryptography (ECC, z.B. [Schuster 2004]) basierend.

Ad I6): Die Anbindung von IoT-Devices an Cloud-Systeme führt buchstäblich zur Spiegelung der unter I1, I2 u. I4 angeführten Probleme. Die selben Angriffsvektoren, die gegen die IoT-Devices selbst gerichtet werden, können ebenso gegen den Cloud-Service gerichtet sein (vgl. OWASP-IoT-I6). Da jedoch im letztgenannten Fall die Daten vieler, u.U. hunderter, tausender oder mehr Geräte im Cloud-Dienst verarbeitet und aggregiert werden, sind die Auswirkungen eines Angriffs um ein Vielfaches höher als beim erfolgreichen Angriff auf ein IoT-Device. Erschwerend für die Anwenderin beziehungsweise den Anwender kommt hierbei zu tragen, dass das Cloud-System sich der Anwenderin oder dem Anwender, wie auch dem IoT-Device als Blackbox präsentiert und die Anwenderin/der Anwender daher, abseits von den persönlichen Einstellungen, wenig oder keinen Einfluss auf die Sicherheit des Dienstes hat.

Ein essentielles Faktum bei der Betrachtung der IoT-Security, das nicht einzelnen Kategorien, wie o.a., zugeordnet werden kann, stellt die (un-)Möglichkeit zum Software-Upgrade bei bereits in Umlauf/Betrieb befindlichen IoT-Devices dar. Die hinlänglich bekannten Verzögerungen und Probleme bei (Security-)Updates von Smartphone-Betriebssystemen geben einen Hinweis, welche Probleme in Software-Updates für IoT-Devices anstehen:

  • Unsichere / instabile / schmalbandige Vernetzung
  • Fehlende Ressourcen (v.a. Speicherplatz) zum Update am Device
  • Forderung nach 24/7-Verfügbarkeit bedingt Updates im laufenden Betrieb
  • Die schiere Menge an IoT-Geräten, die die Anzahl von Smartphones um Größenordnungen übersteigen wird.

Dennoch, und als Konsequenz der vorab abgerissenen Probleme, ist ein stabiler, sicherer Upgrade-Pfad für alle IoT-Devices, die in Umlauf gebracht werden, ein Muss. Nur auf diese Weise ist es letztlich möglich auf Fehler aller Art, ebenso wie neu auftretende Sicherheits-Probleme, zeitnah und umfassend, ohne Zutun der Benutzerin beziehungsweise des Benutzers, zu reagieren.

Zusammenfassend lassen sich aus diesem kurzen Abriss folgende, von [Orebaugh, 2015] übernommene, Maßnahmen ableiten:

  1. Verwendung sicherer Entwicklungs-Praktiken. Die OWASP Internet of Things Top Ten stellen eine gute Grundlage für Security-Kontrollmechanismen zur Verfügung. Dabei geht es um grundlegende Kontrollen wie zum Beispiel starke Authentifizierung und sichere Web-Schnittstellen. Damit würden schon viele der Security-Probleme adressiert, die [auch] von HP Fortify in IoT-Geräten für Endverbraucher gefunden wurden.
  2. Schutz der Daten. Bei IoT wandern Daten und die Netzwerk-Grenzen sind vage. Um den Datenschutz zu garantieren, muss man die Daten sowohl bei der Übertragung als auch im ruhenden Zustand angemessen absichern.
  3. Offenlegung, wie PII (Persönlich identifizierbare Informationen) behandelt werden. Die Produkt-Anbieter sollten klare Auskunft geben, welche persönlichen Informationen gesammelt und geteilt werden und wie man diese schützt.
  4. Verschlüsseln, verschlüsseln und verschlüsseln. Verschlüsselung ist eine entscheidende Komponente für IoT-Security. Die Daten müssen zwischen der Übertragung von einem Gerät auf ein anderes verschlüsselt sein. Das gilt auch zwischen dem Gerät und den mobilen Apps, sowie anderen Netzwerken wie zum Beispiel der Cloud. Zusätzlich sollten Software-Updates für das Gerät verschlüsselt sein.
  5. Führen Sie eine Security-Bewertung durch. Das IT-Security-Team sollte eine eigene Security-Bewertung für das jeweilige Produkt durchführen, um das Gerät, die Applikationen und Kommunikations-Kanäle einschätzen zu können.

Als letzter, nicht in [Orebaugh, 2015] erfasster Aspekt ist die Implementierung eines stabilen, sicheren Software-Update-Mechanismus im IoT-Device (und auch die Bereitstellung der entsprechenden Backend-Infrastruktur) oberste Maxime.

Quellen:

OWASP 2015:
https://www.owasp.org/, Stand: Sept. 2015

KIRAS/GoVAS 2011:T. Linzbichler, E. Graif, G. Mittenecker: GoVAS - Government VoIP Attack Study, in: KIRAS Sicherheitsforschung: Wissenschaf(f)t Sicherheit - Fachtagung Sicherheitsforschung 2011, Tagungsband, FFG / Bundesministerium für Verkehr, Innovation und Technologie (bmvit), Wien, 19.1.2011

OWASP-IoT-2014:
https://owasp.org/www-pdf-archive/OWASP-IoT-Top-10-2018-final.pdf, Stand: Sept. 2015

OWASP-IoT-I1:
https://www.owasp.org/index.php/Top_10_2014-I1_Insecure_Web_Interface (Link nicht mehr abrufbar), Stand: Sept. 2015

OWASP-IoT-I2:
https://www.owasp.org/index.php/Top_10_2014-I2_Insufficient_Authentication/Authorization (Link nicht mehr abrufbar), Stand: Sept. 2015

OWASP-IoT-I3:
https://www.owasp.org/index.php/Top_10_2014-I3_Insecure_Network_Services (Link nicht mehr abrufbar), Stand: Sept. 2015

ISC 2012:https://www.isc2.org/uploadedfiles/(isc)2_public_content/certification_programs/csslp/isc2_wpiv.pdf (Link nicht mehr abrufbar), Stand: Sept. 2015

OWASP-IoT-I4:
https://www.owasp.org/index.php/Top_10_2014-I4_Lack_of_Transport_Encryption (Link nicht mehr abrufbar), Stand: Sept. 2015

Schuster 2004:Michaela Schuster, Die Verwendung elliptischer Kurven in der Kryptografie; Diplomarbeit TU-Wien, 2004

OWASP-IoT-I6:
https://www.owasp.org/index.php/Top_10_2014-I6_Insecure_Cloud_Interface (Link nicht mehr abrufbar), Stand: Sept. 2015

Orebaugh, 2015:Angela Orebaugh, Ph.D in http://www.searchsecurity.de/meinung/Internet-der-Dinge-Was-zu-tun-ist-um-IoT-Security-Realitaet-werden-zu-lassen (Link nicht mehr abrufbar), Stand: Sept 2015

Autor:

Letzte Aktualisierung: 15. Dezember 2015

Für den Inhalt verantwortlich: FH JOANNEUM