Eine Überwachungskamera oder ein Thermostat verbindet sich direkt mit dem zentralen Router des Heimnetzwerks und wird mit einem einfachen Default-Passwort wie 1234 oder 0000 freigeschaltet - ein häufiges Szenario bei IoT-Anwendungen (Internet of Things) und ein Kinderspiel für Hacker: "Hintergrund ist eine falsch verstandene Benutzerfreundlichkeit. Die Anbieter von IoT-Geräten wollen es dem Anwender so einfach wie möglich machen, vernachlässigen dabei aber das Thema Sicherheit sträflich. Security war in diesen Fällen nicht Teil der Designphase des Produkts", erklärt Stefan Strobel, Geschäftsführender Gesellschafter und Gründer des auf Informationssicherheit spezialisierten Unternehmens Cirosec.
Für Hacker seien selbst im Programmcode der Firmware eingebettete Passwörter einfach auszulesen, die dem Hersteller bei der Wartung helfen. "Ich nenne das Security by Obscurity: Der Entwickler glaubt fälschlicherweise, dass niemand das Passwort findet, weil es nirgends dokumentiert ist. Das zeigt mangelndes Sicherheitsbewusstsein und -wissen", so Strobel weiter. Er rät den Herstellern in diesem Fall dazu, Passwörter oder auch Kryptografie-Schlüssel in speziellen TPM (Trusted Platform Module)- oder Crypto-Chips abzulegen, damit sie nicht ausgelesen werden können.
Spannungsfeld: Kosten und Time to Market versus Sicherheit
Doch Hardware-Chips und ein stärkerer Fokus auf Sicherheit beim Design der Anwendung erhöhen die Kosten bei der Entwicklung und verzögern die Marktreife des Produkts. Insbesondere Startups, die ihr Produkt schnell auf den Markt bringen wollen oder müssen, stehen in diesem Spannungsfeld. Oft bleibt dabei IT-Sicherheit auf der Strecke. "Viele IoT-Anbieter haben wenig Erfahrung mit Security und unterschätzen die vielen IT-Probleme, die sie sich mit IoT-Geräten ins Haus holen. So fehlt beispielsweise häufig eine Update-Strategie für die Behebung von Sicherheitslücken. IoT-Sicherheit ist kein einmaliges Ereignis, sondern Firmen müssen sich auf Veränderungen einstellen und das Produkt auch in Zukunft unter dem Aspekt Sicherheit betreuen", betont Dirk Kollberg, Senior Security Researcher bei Kaspersky.
Beispiel Eins: Durch die jährlich steigende Rechenleistung können Hacker ältere Verschlüsselungsmethoden schneller aufbrechen. Daher müssen Entwickler schon beim Design der Anwendung darauf achten, dass die ursprünglich eingesetzten Kryptografie-Schlüssel im Laufe der Zeit durch komplexere Schlüssel ersetzt werden können. Nur dann können sie ein hohes Sicherheitsniveau auch in Zukunft halten.
Beispiel Zwei: Viele Entwickler nutzen Open Source-Libraries etwa für die Programmierung von SSL. Wenn es dort Schwachstellen gibt und die Libraries aktualisiert werden, müssen Unternehmen die Veränderungen in ihre Software übernehmen und an den Nutzer weitergeben. Sonst drohen ernsthafte Konsequenzen: "Angreifer suchen sich immer den einfachsten Weg und greifen die Komponente an, die am wenigsten geschützt ist", so Dirk Kollberg.
Vier Einfallstore für Hacker
Hackern bieten sich bei IoT-Anwendungen vier Einfallstore: die Endgeräte, die App auf dem mobilen Gerät, das Backend und die Übertragungswege. "Aus Sicht des Angreifers ist immer die Höhe des ROI entscheidend. Je näher am Backend, desto höher ist der Skaleneffekt für den Angreifer aus wirtschaftlicher Perspektive, da er am Backend viele Daten abgreifen kann und Kontrolle über alle verbundenen Geräte erhält", erklärt Udo Schneider, Security Evangelist bei Trend Micro. Er rät Firmen daher, besonderen Fokus auf den Schutz des zentralen Backends zu legen. Da sich das Backend häufig in der Cloud befinde und meist auf Standard Web Stack basiere, seien auch IoT-Anwendungen für übliche Angriffsarten wie SQL Injection oder XSS anfällig.
Der Angriff auf ein einzelnes Gerät über die Luftschnittstelle lohne sich für Hacker weniger, da Smart Devices oft nicht sehr intelligent seien und nur einen Bluetooth-Chip umfassten, der beispielsweise einen Motor steuert. Größer ist laut Schneider die Gefahr bei intelligenteren Geräten wie Smartwatches: "Hier geben Beschleunigungssensoren Aufschluss über die Aktionen des Benutzers, so dass ein gewiefter Hacker darüber die PIN erkennen kann."
Laut Ajay Jasti, Lead Global IoT Practice bei Dell, muss eine IoT-Lösung End-to-End-Sicherheit vom Endgerät über den Übertragungsweg bis hin zum Backend-System im Unternehmen bieten. "Grundlagen dafür sind Standards für Authentifizierung, Autorisierung und Verschlüsselung auf Basis des Least-Privilege-Prinzips: Jeder Benutzer, jedes System und jeder Dienst erhält nur die Rechte, die für eine spezielle Funktion absolut notwendig sind. Je mehr Rechte ich dem System gebe, umso mehr Rechte kann auch die Malware übernehmen." Seiner Meinung nach ist der Schutz der Endgeräte sehr wichtig, da sie eine Unmenge an Daten erzeugen. Da es aber angesichts der Vielfalt der Endpunkte laut Jasti keine "One-size-fits-all"-Lösung gibt, plädiert er für den Einsatz von Netzwerk-Gateways mit integrierten Sicherheitsfunktionen, welche die Daten der Sensoren oder anderer Endpunkte sammeln und sie zur Auswertung sicher in das Netzwerk oder die Cloud übertragen.
Sicherheit beginnt in der Design-Phase
"Sicherheit von IoT-Anwendungen beginnt grundsätzlich bereits bei beim Design und der Architektur des Systems und sollte nicht erst hinzugefügt werden, wenn die Anwendung fertig ist", betont Jasti. Im ersten Schritt stehe daher immer eine Bedrohungs- und Risikoanalyse: Wie handelt der Angreifer und was wird er machen? Wie hoch ist die Eintrittswahrscheinlichkeit? Welche Daten werden übertragen, und welche Risiken sind für diese Daten ertragbar? "Persönliche Daten unterliegen immer dem Datenschutz. Unternehmen müssen daher immer darauf achten, dass sie den Compliance-Anforderungen entsprechen", so Jasti weiter.
Sind diese grundsätzlichen Fragen geklärt, werden im Idealfall die passenden Maßnahmen für die sichere Entwicklung definiert und die Anwendungsentwickler entsprechend geschult. "Unternehmen sollten hier Richtlinien und Best Practices für die sichere Entwicklung von IoT-Anwendungen festlegen, etwa zur Anbindung des Backends oder der Art der Verschlüsselung. Verschlüsselung ist nur so sicher wie die Schlüssel-Verwaltung. Daher sollte das IoT-Gerät den Schlüssel in Hardware wie TPM- oder Crypto-Chips ablegen. Das ist eine klare Architekturentscheidung", erläutert Stefan Strobel von Cirosec.
Umfangreiches Testing und Update-Strategie
Wie die anderen befragten Experten auch empfiehlt er zur Orientierung und als Leitfaden für die sichere Entwicklung von IoT-Anwendungen ISO-Normen wie die ISO 27034, den Microsoft Security Development Lifecycle oder vor allem die OWASP Top 10-Listen (Open Web Application Security Project) etwa zu den häufigsten Bedrohungen bei Webanwendungen oder den Risiken bei mobilen Geräten. "Die OWASP-Listen enthalten auch Hinweise und Verweise auf Maßnahmen, um diese Schwachstellen zu schließen oder Angriffe zu vermeiden", erklärt Strobel.
Udo Schneider von Trend Micro rät den Firmen, bereits in der Design-Phase externe Sicherheits-Experten an Bord zu holen sowie den Entwicklern Tools für Tests des Quellcodes an die Hand zu geben. Anschließend sollten umfangreiche Penetrationstests folgen, um Sicherheitslücken zu entdecken. "Diese Tests sind natürlich sehr aufwändig und stehen in Konflikt zu einem schnellen Marktstart der Produkte. Der Schaden ist aber viel größer, wenn die Lücke erst entdeckt wird, wenn das Produkt bereits auf dem Markt ist", sagt Schneider. "Es gibt genügend Best Practices für die sichere Entwicklung von Anwendungen. Wenn IoT-Anbieter diese Tipps beherzigen, dürften sie keine Probleme bekommen. Letztendlich ist Sicherheit auch hier eine Frage der Kosten und der Risikoabwägung."
So werden IoT-Anwendungen sicher
Folgende praktische Sicherheits-Tipps stammen von den im Text zitierten Sicherheitsexperten:
Security by Design und sichere Entwicklung gemäß die ISO 27034, den Microsoft Security Development Lifecycle oder den OWASP Top 10-Listen.
Einsatz stärkerer Passwörter am Endgerät, Verzicht auf Default-Passwörter wie 1234 oder 0000.
Passwörter niemals im Klartext im Backend speichern (Hash und und Salt).
Nur moderne WLAN-Sicherheitsverfahren nutzen (WPA2 als Standard, kein WEP).
Langfristige Update-Strategie zum Schließen von Sicherheitslücken auf den Endgeräten und im Backend.
Kryptografie-Schlüssel nicht im Code ablegen, sondern in spezieller Hardware wie TPM- oder Crypto-Chips.
Verschlüsselte Verbindung zum Backend mit Key Exchange und Verifizierung über Passwort und Zertifikate, um Man-in-the-Middle-Attacken zu verhindern.
Bewährte Standards, Frameworks und Bibliotheken benutzen (Verschlüsselung nicht selbst programmieren).
Least Privilege: Rechte auf die zentrale(n) Funktion(en) beschränken.