IoT-Sicherheit: Risiken und Schutzmaßnahmen für vernetzte Geräte

IoT-Sicherheit (Internet of Things Security) bezeichnet alle technischen und organisatorischen Maßnahmen, die den Schutz vernetzter physischer Geräte vor unbefugtem Zugriff, Manipulation und Missbrauch gewährleisten. IoT-Geräte umfassen ein breites Spektrum: Smart-TVs, IP-Kameras und WLAN-Thermostate im Verbraucherbereich bis hin zu industriellen Sensoren, Steuerungssystemen und medizinischen Geräten im Unternehmensumfeld. Das gemeinsame Merkmal aller IoT-Geräte ist die Verbindung physischer Objekte mit IP-Netzwerken - und damit die Eröffnung digitaler Angriffsvektoren auf zuvor isolierte, oft sicherheitskritische Systeme.

Bedrohungslage: Warum IoT ein Hochrisiko-Bereich ist

Die IoT-Bedrohungslage hat sich in den letzten Jahren dramatisch verschärft. Drei strukturelle Probleme sind dabei besonders relevant:

Drei strukturelle Probleme dominieren die IoT-Bedrohungslage:

1. Mirai-Botnetz und DDoS-Angriffe: 2016 infizierte Mirai 600.000+ IoT-Geräte (IP-Kameras, Router, DVR) per Dictionary-Angriff gegen Telnet/SSH mit Default Credentials und führte einen verheerenden DDoS-Angriff gegen Dyn-DNS durch - Teile des Internets waren stundenlang nicht erreichbar. Der Mirai-Quellcode ist öffentlich, Nachfolger wie Mozi, Emotet-IoT und BotenaGo sind bis heute aktiv. Ein kompromittiertes IoT-Gerät wird Teil eines Angriffsnetzes gegen Dritte.

2. Default Credentials: Viele Hersteller liefern Geräte mit identischen Passwörtern aus (admin/admin, root/root, admin/1234). Shodan findet millionenfach internet-exponierte Geräte mit diesen Defaults. Das grundlegende Problem: Nutzer ändern Passwörter nicht - oft fehlt sogar die technische Möglichkeit dazu. Angreifer scannen automatisiert mit öffentlichen Listen bekannter Defaults.

3. Fehlende und ausstehende Updates: Hersteller liefern Geräte ohne definierten Update-Zeitraum. Firmware-Updates erfordern oft manuelle Eingriffe, End-of-Life-Modelle erhalten nach nur 2-3 Jahren keine Patches mehr, und kritische Schwachstellen bleiben dauerhaft offen. Die typische Nutzerantwort: "Das Gerät funktioniert - warum updaten?"

Ein konkretes Beispiel zeigt, wie real diese Risiken sind: Sicherheitsforscher von Cisco Talos entdeckten zwei Remote-Code-Execution-Schwachstellen in einer WLAN-fähigen Heißluftfritteuse - ein Küchengerät, das durch seine Netzwerkanbindung zur Angriffsfläche wird. Mehr dazu im Blog-Artikel Remote-Code-Execution in Heißluftfritteuse.

Die Dimension des Problems zeigt eine weitere Perspektive: Eine einzelne kompromittierte IP-Kamera oder ein ungepatchter Router können als Einstiegspunkt dienen, von dem aus sich Angreifer lateral durch das gesamte Unternehmensnetzwerk bewegen - auf Fileserver, ERP-Systeme und Cloud-Dienste. Das IoT-Gerät selbst ist dabei oft nicht das Ziel, sondern das Werkzeug.

Häufige Schwachstellen: OWASP IoT Top 10

Das Open Web Application Security Project (OWASP) hat die zehn häufigsten IoT-Schwachstellen katalogisiert:

#	Schwachstelle	Details
I1	Schwache, vorhersehbare oder hart kodierte Passwörter	Default Credentials; Passwörter im Firmware-Image eingebettet; Admin-Interface ohne Änderungspflicht
I2	Unsichere Netzwerkdienste	Unnötige Ports offen (Telnet, FTP, UPnP, mDNS); Dienste ohne Authentifizierung; Tausende Telnet-Ports auf Shodan sichtbar
I3	Unsichere Ecosystem-Interfaces	Web-Interface, API, Mobile-App, Cloud-Backend schlecht gesichert; SQL Injection und Command Injection über Konfigurationsfelder
I4	Fehlende Update-Mechanismen	Kein Auto-Update, keine signierte Firmware-Validierung; Update-Kanal ohne TLS (Man-in-the-Middle!); keine Rollback-Möglichkeit
I5	Unsichere oder veraltete Komponenten	OpenSSL, libexpat, uClibc jahrelang nicht aktualisiert; Linux-Kernel mit öffentlichen CVEs; Embedded-Webserver (lighttpd, mini_httpd) mit Schwachstellen
I6	Unzureichender Schutz der Privatsphäre	Sensordaten, Kamerabilder, Sprachaufnahmen unverschlüsselt übertragen; kein Consent-Management (DSGVO-relevant!)
I7	Unsichere Datenübertragung und -speicherung	HTTP statt HTTPS für Konfiguration; Zugangsdaten unverschlüsselt im Flash-Speicher
I8	Fehlende Geräteverwaltung	Kein Asset-Inventory; keine zentrale Überwachung; Shadow IoT durch Mitarbeiter (BYOD)
I9	Unsichere Standardeinstellungen	Debug-Interfaces (UART, JTAG) aktiv; Telnet aktiviert, UPnP standardmäßig an; keine Network-Isolation im Default-Setup
I10	Mangelnde physische Sicherheit	UART/JTAG-Schnittstellen zugänglich (Firmware-Extraktion in Minuten); kein Secure Boot; physischer Zugang = Root-Zugang

Sicherheitsmaßnahmen

Wirksamer IoT-Schutz basiert auf vier Säulen:

Netzwerksegmentierung

Grundprinzip: IoT-Geräte gehören niemals ins produktive Unternehmensnetz. Empfohlene VLAN-Segmentierung: VLAN 10 für das Produktionsnetz (Server, Workstations), VLAN 20 für IoT-Geräte (Drucker, Smart-Building, Kameras, Sensoren), VLAN 30 für BYOD/Gäste sowie VLAN 40 für industrielle OT-Systeme/PLCs falls vorhanden.

Firewall-Regeln zwischen den Segmenten: VLAN 20 (IoT) → VLAN 10 (Prod): DENY ALL; VLAN 10 → VLAN 20: nur explizit erlaubte Zugriffe; VLAN 20 → Internet: nur benötigte Cloud-Dienste auf einer Whitelist; innerhalb VLAN 20: Mikro-Segmentierung für kritische Geräte.

Praktische Umsetzung erfordert Managed Switches mit VLAN-Unterstützung (802.1Q), separate SSIDs pro VLAN im WLAN, getrenntes DHCP pro VLAN und keine Default-Route aus dem IoT-VLAN ins Produktionsnetz.

Zero-Trust für IoT bedeutet: Jedes Gerät gilt als nicht vertrauenswürdig, erhält per Least Privilege nur Zugriff auf exakt benötigte Dienste, und sein Traffic wird kontinuierlich auf Anomalien überwacht.

Firmware-Management und Updates

Vor der Beschaffung: Herstellerpolitik prüfen (wie lange werden Updates bereitgestellt?), CVE-Historie prüfen (wie reagiert der Hersteller auf gemeldete Schwachstellen?), No-Name-Geräte ohne Support-Adresse meiden und Hersteller mit PSIRT-Team und Bug-Bounty-Programm bevorzugen.

Im Betrieb: Firmware-Version aller Geräte im Asset-Inventar erfassen, RSS/E-Mail-Benachrichtigungen für Hersteller-Security-Advisories abonnieren, mindestens quartalsweise Update-Checks durchführen und für kritische CVEs einen definierten Patch-SLA einhalten (z.B. 14 Tage).

Technische Härtung: Firmware-Integrität per SHA256-Hash vom Hersteller verifizieren, Updates nur über verschlüsselte Kanäle (HTTPS, nicht HTTP) einspielen, Auto-Update aktivieren wo verfügbar und EOL-Geräte durch Hardware-Austausch ersetzen statt sie dauerhaft zu betreiben.

Firmware-Analyse für Sicherheitsprüfungen: Binwalk für Firmware-Entpackung und Analyse, Ghidra/IDA für Reverse Engineering, Firmwalker für automatisierte Suche nach eingebetteten Credentials und Keys, EMBA als umfassender Automated Firmware Analyzer.

Passwort-Management und Authentifizierung

Default Credentials müssen bei Inbetriebnahme sofort geändert werden. Jedes Gerät erhält ein einzigartiges Passwort (kein einheitliches "IoT1234!"), idealerweise verwaltet in einem Passwort-Manager (KeePass, Bitwarden). Wo technisch möglich, sollte Zertifikat-basierte Authentifizierung statt Passwörtern eingesetzt werden.

Passwort-Anforderungen: mindestens 16 Zeichen, alphanumerisch mit Sonderzeichen, niemals im Klartext übertragen (HTTPS-Admin-Interface erzwingen), keine eingebetteten Passwörter in der Firmware (Prüfung via Binwalk).

Weitere Zugangssicherung: MFA für Admin-Webinterfaces wo technisch möglich, Token-basierte API-Zugänge (keine Basis-Authentifizierung), SSH statt Telnet für alle Remote-Zugänge sowie PAM-Lösungen (CyberArk, Keeper) für IoT-Admin-Credentials mit Session-Recording für kritische Geräte und Just-in-Time-Zugang für Wartungszugriffe.

Verschlüsselung und sichere Kommunikation

Protokoll-Auswahl für IoT-Kommunikation: MQTT nur über TLS (Port 8883 statt unverschlüsseltem Port 1883), mit Client-Zertifikaten für gegenseitige Authentifizierung und Access Control Lists im MQTT-Broker (z.B. Mosquitto). HTTP/REST ausschließlich über HTTPS (TLS 1.2+) mit HSTS und Zertifikats-Pinning in mobilen Companion-Apps. CoAP über DTLS (Datagram TLS) mit PSK oder Raw Public Key Modus.

Verschlüsselung gespeicherter Daten: Flash-Speicher für Credentials verschlüsseln, Secure Element oder TPM wo hardware-seitig verfügbar nutzen, Schlüssel niemals im Klartext in Konfigurationsdateien ablegen.

Bluetooth-Sicherheit

Bluetooth ist eine der häufigsten Kommunikationstechnologien in IoT-Geräten (Fitness-Tracker, Smart-Locks, BLE-Sensoren, Headsets) und birgt eigene Angriffsvektoren.

Bekannte Schwachstellenklassen:

KNOB-Angriff (CVE-2019-9506): Angreifer können die Schlüssellänge bei Bluetooth-Verbindungen auf 1 Byte reduzieren und so Brute-Force-Angriffe auf die Verschlüsselung ermöglichen. Betrifft nahezu alle Bluetooth-Implementierungen vor den Patches von 2019.
BLURtooth (CVE-2020-15802): Eine Schwachstelle im CTKD-Mechanismus (Cross-Transport Key Derivation) von Bluetooth 4.2 bis 5.0 erlaubt es Angreifern, gespeicherte Authentifizierungsschlüssel zu überschreiben oder die Verschlüsselung auf eine schwächere Version herabzustufen. Bluetooth 5.1 entschärft dies durch eine Einschränkung der Schlüsselüberschreibung. Hersteller haben die Schwachstelle mit Firmware-Updates behoben — nicht gepatchte Geräte bleiben anfällig.
Blueborne (2017): Acht Schwachstellen in Bluetooth-Stacks verschiedener Betriebssysteme ermöglichten Remote Code Execution ohne Pairing. Verdeutlicht, dass selbst inaktive Bluetooth-Verbindungen angreifbar sind.

Schutzmaßnahmen für Bluetooth in IoT-Umgebungen:

Bluetooth deaktivieren wenn nicht benötigt — viele IoT-Geräte lassen Bluetooth permanent aktiv, obwohl es nur für die Erstkonfiguration gebraucht wird
Firmware-Updates konsequent einspielen: Bluetooth-Patches werden oft als Low-Priority eingestuft und bleiben aus
Bluetooth Low Energy (BLE) statt klassischem Bluetooth bevorzugen wo möglich; BLE bietet modernere Sicherheitsmodelle (LE Secure Connections mit ECDH)
Paired-Device-Listen regelmäßig prüfen und nicht mehr benötigte Pairings entfernen — besonders in öffentlichen Bereichen
Für kritische Anwendungen (Smart-Locks, medizinische Geräte): Gerätezertifizierung nach ETSI EN 303 645 verlangen, die auch Bluetooth-Sicherheitsanforderungen umfasst

IoT im Unternehmenskontext

BYOD und Schatten-IoT

Der wachsende Trend, private Geräte ins Büro mitzubringen (BYOD), betrifft zunehmend auch IoT-Geräte: Mitarbeiter schließen Smart-Lautsprecher, WLAN-Steckdosen oder Fitness-Tracker ans Firmennetz an - ohne Wissen der IT-Abteilung. Dieses "Schatten-IoT" ist besonders gefährlich, weil:

Keine Sicherheitsprüfung vor dem Anschluss stattfindet
Geräte oft im selben Netz wie Workstations landen
IT-Abteilungen oft keine vollständige Sicht auf alle angeschlossenen Endgeräte haben

Eine vollständige IoT-Asset-Discovery - beispielsweise mit Shodan-ähnlichen internen Scan-Tools oder passiven Netzwerküberwachungslösungen - ist die Grundlage jedes IoT-Sicherheitsprogramms. Mehr zu IoT-Risiken in Firmennetzen im Blog-Artikel IoT: Sicherheit und Risiken des Internet of Things.

Smart Building und Gebäudeautomation

Moderne Bürogebäude integrieren zahlreiche IoT-Systeme: Klimaanlagen, Zugangssysteme, Aufzugssteuerungen, Brandmeldeanlagen und Beleuchtungssteuerungen. Diese Systeme nutzen oft BACnet, KNX oder Modbus - Protokolle ohne inhärente Authentifizierung. Angreifer nutzen internet-exponierte BACnet-Installationen regelmäßig für physische Sabotage oder als Sprungbrett ins IT-Netz.

Industrie 4.0 und industrielles IoT (IIoT)

In der Industrie verbinden IIoT-Systeme Produktionsmaschinen, Sensoren und SCADA-Systeme. Hier gelten besondere Anforderungen, da Kompromittierungen physische Schäden verursachen können. Die Abgrenzung zwischen IoT und OT ist in diesem Kontext fließend - die Schutzprinzipien aus der OT/ICS Industrial Security gelten entsprechend.

Regulierung: EU Cyber Resilience Act und ETSI EN 303 645

ETSI EN 303 645 (2020) ist der Baseline-Standard für Consumer-IoT und definiert 13 Pflicht-Anforderungen: keine universellen Default Passwords, Schwachstellenmeldeverfahren, Software-Aktualisierbarkeit, sichere Zugangsdaten-Speicherung, verschlüsselte Kommunikation, minimale Angriffsfläche, Softwareintegrität, Datenschutz, Resilienz, prüfbare Telemetrie, Datenlöschung durch Nutzer, sichere Installation und Eingabe-Validierung. ETSI EN 303 645 ist die Grundlage für den EU Cyber Resilience Act.

EU Cyber Resilience Act (CRA) (in Kraft 2024, Übergangsfristen bis 2027) ist verbindlich für nahezu alle Produkte mit digitalen Elementen. Hersteller müssen Security by Design umsetzen, einen aktiven Schwachstellen-Management-Prozess (PSIRT) betreiben, Sicherheitsupdates mindestens 5 Jahre nach Markteintritt bereitstellen, CVEs dokumentieren und eine CE-Konformitätserklärung ausstellen. Sanktionen: bis 15 Mio. EUR oder 2,5% des weltweiten Jahresumsatzes. Praktische Auswirkung: End-of-Life ohne Updates wird regulatorisch verboten.

BSI TR-03148 definiert Sicherheitsanforderungen an Breitbandrouter. Weitere IoT-spezifische BSI-Empfehlungen sind auf bsi.bund.de verfügbar.

NIS2 und IoT: Unternehmen unter NIS2 müssen IoT-Risiken in ihre Risikoanalyse einbeziehen, Sicherheitsanforderungen an IoT-Hersteller und -Lieferanten in der Supply Chain stellen und IoT-bedingte Sicherheitsvorfälle melden.

IoT-Sicherheitstests: Shodan, Firmware-Analyse und Pentest

Eine fundierte Sicherheitsprüfung von IoT-Umgebungen umfasst drei Ebenen:

Eine fundierte IoT-Sicherheitsprüfung gliedert sich in drei Phasen:

Phase 1: Reconnaissance und Asset Discovery. Shodan-Suche nach exponierten Geräten des eigenen Unternehmens (Queries: org:"Unternehmensname", Filter: port:23 für Telnet, port:554 für RTSP-Kameras). Interne Discovery per Nmap und schnelle Port-Scans mit Masscan.

Phase 2: Firmware-Analyse. Die Firmware wird vom Hersteller heruntergeladen, aus dem Update-Traffic extrahiert (Wireshark + HTTP-Proxy) oder physisch via UART/JTAG gewonnen. Analysetools:

# Binwalk - Firmware-Analyse-Toolchain
binwalk -e firmware.bin              # Extrahieren aller Dateisystem-Artefakte
binwalk -B firmware.bin              # Signatur-Scan

# Firmwalker - Automatisierte Schwachstellensuche
./firmwalker.sh /extracted/firmware/

# EMBA - Comprehensive Firmware Analyzer
sudo ./emba.sh -f firmware.bin -l log/ -p ./config/full_scan.cfg

Phase 3: Dynamischer Test am laufenden Gerät. Web-Interface-Tests mit Burp Suite (manuell: Authentication Bypass, Command Injection, CSRF) sowie automatisiert mit Nikto und OWASP ZAP. MQTT-Tests mit mosquitto_sub gegen alle Topics (Auth-Test). Netzwerk-Traffic-Analyse mit Wireshark: Werden Credentials im Klartext übertragen? Wird das TLS-Zertifikat validiert?

Typische Findings bei IoT-Pentests

Erfahrungsgemäß fallen bei IoT-Sicherheitsprüfungen häufig dieselben Schwachstellen auf:

Default Credentials nicht geändert (betrifft regelmäßig 30-60% der geprüften Geräte)
Admin-Interface über HTTP ohne TLS erreichbar
Telnet-Dienst aktiv und zugänglich
Firmware-Update ohne Signaturprüfung (ermöglicht Firmware-Manipulation)
UPnP aktiv und von außen erreichbar (automatisches Port-Forwarding durch Angreifer nutzbar)
Credentials im Firmware-Image im Klartext eingebettet
Veraltete Softwarekomponenten mit bekannten CVEs (oft Jahre ohne Update)

Zusammenfassung: Minimale Schutzmaßnahmen für Unternehmen

Sofortmaßnahmen: IoT-Asset-Inventar erstellen, Default Credentials auf allen Geräten ändern, IoT-Geräte in separates VLAN verschieben, internet-exponierte IoT-Dienste identifizieren und abschalten sowie Firmware-Versionen erfassen und veraltete Versionen aktualisieren.

Mittelfristig: Patch-Management-Prozess für IoT definieren, Netzwerk-Monitoring auf dem IoT-Segment aktivieren, BYOD-Richtlinie (private IoT-Geräte ins Gäste-VLAN), Beschaffungsrichtlinie (nur Hersteller mit definierten Update-Zusagen) sowie einen IoT-Penetrationstest durchführen.

Governance: IoT-Risiken in die Risikoanalyse aufnehmen (NIS2, ISO 27001), Sicherheitsanforderungen für IoT-Hersteller in Lieferantenverträgen verankern, ein Incident-Response-Playbook für IoT-Vorfälle erstellen und CRA-Compliance prüfen (ab 2027 verpflichtend für Hersteller).

IoT-Sicherheit ist keine optionale Erweiterung einer IT-Sicherheitsstrategie, sondern ein notwendiger Bestandteil. Mit der zunehmenden Verbreitung vernetzter Geräte in Unternehmen - von der Gebäudesteuerung bis zur Produktionsanlage - wächst die Angriffsfläche stetig. Die gute Nachricht: Die grundlegenden Schutzmaßnahmen wie Netzwerksegmentierung, konsequentes Passwort-Management und ein strukturiertes Update-Verfahren sind bekannt und umsetzbar. Der Aufwand ist überschaubar - das Risiko, ihn nicht zu betreiben, ist es nicht.