M2M-Hotspot
Es braucht eine Security-Stelle!
Cyber-Attacken auf vernetzte Embedded-Systeme und Automatisierungskomponenten können immense Schäden anrichten. Deshalb braucht es ein von Experten betriebenes Monitoringsystem. Dieses System sollte Meldungen über Cyber-Attacken auf freiwilliger Basis entgegennehmen, bewerten, kommentieren und einer breiten Öffentlichkeit zur Verfügung stellen. Nur so lassen sich erkannte Schwachstellen rasch beseitigen und das Sicherheitsniveau der M2M-Anwendungen insgesamt verbessern.
Unzählige M2M-Anwendungen kommunizieren inzwischen per Internet beziehungsweise nutzen Internet-basierte Dienste. Viele davon sind sogar Bestandteil kritischer Infrastrukturen, zum Beispiel das Lastmanagement in elektrischen Versorgungsnetzen. Dem Schutz vor Cyber-Angriffen wurde bei solchen Anwendungen bis dato wenig Aufmerksamkeit zuteil. Ein spezielles CERT – ein Computer Emergency Response Team – könnte diese Situation mittelfristig ändern.
Mit einem CERT ist im allgemeinen Sprachgebrauch eine Gruppe von Sicherheitsfachleuten gemeint, die hinsichtlich der Lösung konkreter oder akuter Sicherheitsprobleme in unterschiedlichen Organisationsformen zusammenarbeiten. Dabei geht es in erster Linie darum, Sicherheitsprobleme in IT-Anwendungen und Baugruppen zu untersuchen. Die Ergebnisse könnten als Warnungen und Lösungsvorschläge über geschlossene Mail-Listen oder eine frei zugängliche Website verbreitet werden. Bei einer Web-Veröffentlichung wäre natürlich darauf zu achten, dass keine Detail-Informationen für potenzielle Angreifer kommuniziert werden. In der M2M-Welt könnte ein CERT die folgenden Aufgaben bearbeiten:
- Organisationsaufbau eines M2M-CERT sowie der Betrieb einer Web-site mit Alarmmeldungen und Hinweisen zu erkannten Schwachstellen, akuten Bedrohungen und Bedrohungsrisiken, die für Betreiber und Anbieter von M2M-Anwendungen und Systemen von Bedeutung sind.
- Betrieb einer Meldestelle, um regis-trierten Benutzern die Möglichkeit zu bieten, Vorfälle und relevante Sachverhalte zu melden, die dann gemäß dem Traffic Light Protocol (TLP) behandelt werden.
- Realisierung eines Verfahrens, um anonyme Meldungen entgegenzunehmen, zu analysieren und bei Eignung auf der M2M-CERT-Website zu veröffentlichen.
- Zusammenarbeit mit anderen Orga-nisationen auf nationaler und euro-päischer Ebene, zum Beispiel dem CERT der European Union Agency for Network and Information Security (ENISA) und dem European Cybercrime Centre (EC3).
- Laufendes Auswerten aktueller Alarmmeldungen der ICS-CERT-Website (http://ics-cert.us-cert.gov/) des U.S. Department of Homeland Security. Von diesem CERT werden schon seit einigen Jahren entsprechende Vorfälle aus der Automatisierung (ICS = Industrial Control Systems) ausgewertet.
- Realisierung und Weiterentwicklung geeigneter Maßnahmen (beispielsweise M2M-Honeypots), um ein möglichst präzises Bild der jeweils aktuellen Angriffskonzepte zu erhalten.
Die Aufklärung liegt im Argen
Neben den zuvor aufgeführten Punkten wäre die nachhaltige Aufklärung einer bestimmten Zielgruppe hinsichtlich der Schwachstellen und Gefahrenquellen eine weitere wichtige Aufgabe für ein M2M-CERT. Dabei ist zu berücksichtigen, dass sehr vielen Marktteilnehmern die Risiken der eigenen Systemlösung beziehungsweise die Sicherheitsdetails der zum Einsatz kommenden Komponenten noch nicht einmal bekannt sind. Hierzu zwei typische Beispiele:
1. LAN-Schnittstelle plus Webserver: In unzähligen Anwendungen sind integrierte MSR- beziehungsweise M2M-Baugruppen-Webserver mit einfachem Passwortschutz per Internet erreichbar (siehe Grafik). Die LAN-Schnittstelle der MSR-Baugruppe wird mit einem geeigneten Router verbunden. Im Router wird das „Port Forwarding“ für den TCP-Port 80 eingeschaltet, der DynDNS-Dienst aktiviert und ein entsprechender Account eingerichtet. Dadurch kann man von unterwegs oder von jedem anderen beliebigen Ort aus über einen leicht zu merkenden Hostnamen auf den Webserver der MSR-Baugruppe zugreifen. Die ständig wechselnde IP-Adresse des Routers im Internet wird durch das dynamische DNS ausgeglichen. Das Problem einer solchen Lösung ist, dass nun praktisch jeder, der Benutzername und Passwort kennt, per Internet die MSR-Daten der Baugruppe lesen und schreiben kann. Da als Name/Passwort-Kombination vielfach die Standardein-stellungen der Hersteller oder sehr einfache Kombinationen (zum Beispiel „admin/admin“) genutzt werden, ist der weltweiten missbräuchlichen Nutzung im wahrsten Sinne des Wortes Tür und Tor geöffnet. Noch riskanter als die Benutzung eines dynamischen DNS-Dienstes ist die Verwendung einer fixen IP-Adresse. In diesem Fall ist die MSR-Baugruppe immer unter der gleichen IP-Adresse per Internet erreichbar. Angriffsziel-Suchmaschinen wie Shodan, die das gesamte Internet hinsichtlich erreichbarer Geräte indizieren und die Ergebnisse als Website mit Hyperlinks für jeden frei zugänglich anbieten, werden früher oder später auch den Webserver der MSR-Baugruppe finden und den entsprechenden Link veröffentlichen.
2. OSGi plus TR-069: In immer mehr M2M-Gateways (zum Beispiel der neuen Smart-Home-Plattform QIVICON der Telekom) kommt OSGi zum Einsatz. OSGi spezifiziert eine Hardware-unabhängige dynamische Softwareplattform, die über ein hochentwickeltes Komponentenmodell verfügt. OSGi setzt eine Java-Laufzeitumgebung voraus. Das OSGi-Komponentenkonzept ermöglicht die Entwicklung von Anwendungen und Diensten durch Dritte, die nachträglich installiert und zur Ausführung gebracht werden können – vergleichbar zum App-Konzept in Apple-iOS und Google-Android. In zahlreichen OSGi-Implementierungen findet man das TR-069 CPE WAN Management Protocol des Broadband-Forums. TR-069 ist der Name eines speziellen Device-Management-Protokolls, um sogenannte CPE (Customer Premises Equipment = Kundenendgeräte) per ACS (Auto-Configuration Server) vollständig automatisch zu konfigurieren und zu managen. Die Idee zu TR-069 kommt aus dem Umfeld der Telekommunikationsdienstanbieter. Das Protokoll selbst wird seit Jahren auf unzähligen DSL-Routern eingesetzt. Das Sicherheitsproblem mit diesem Protokoll ist, dass ein Dienstanbieter ohne Wissen und Zustimmung des Anwenders jederzeit per Internet die aktuelle Konfiguration eines Gateways – inklusive aller Passwörter und Sicherheitseinstellungen – auslesen und verändern kann. Aus diesem Grund wird eine TR-069-Implementierung von Sicherheitsexperten als „werksseitiges Backdoor“ angesehen. Der TR-069-Einsatz in professionellen M2M-Anwendungen ist daher sehr fragwürdig.
Offene Fragen
Völlig ungeklärt ist zum gegenwärtigen Zeitpunkt die Organisation und Finanzierung einer solchen möglichen M2M-CERT. Bisher wurde die Idee lediglich in der M2M-Initiative Deutschland der Arbeitsgruppe 2 des nationalen IT-Gipfels diskutiert und in einer Handlungsempfehlung niedergeschrieben. Der Autor steht unter der E-Mail-Adresse [email protected] als Ansprechpartner für Vorschläge und Anmerkungen zur Verfügung, die bei der Realisierung einer solchen Einrichtung helfen können.
Autor: Klaus-Dieter Walter ist Mitglied der Geschäftsleitung bei SSV Software Systems und gehörte viele Jahre dem Vorstand der M2M Alliance an.












