M2M Security – Wie Geräte sicher miteinander kommunizieren

M2M-Anwendungen bringen in Sachen Sicherheit neue Herausforderungen mit sich. Wolfram Lutz beschäftigt sich schon seit mehreren Jahren mit den Themen IT-Security und M2M und kennt die Besonderheiten von M2M Security. Im Interview spricht er über die notwendigen Sicherheitsstandards und warum es so wichtig ist, diese von Anfang an im Blick zu haben.

 doubleSlash hat als Integrator eine ganzheitliche Sicht auf M2M-Projekte. In Bezug auf IT-Sicherheit bringen solche Projekte einige Besonderheiten mit sich. Welche sind das deiner Erfahrung nach?

M2M heißt ja Machine-to-Machine-Kommunikation. Das beinhaltet z.B. auch Fernwartung von kritischen Anlagen wie die Klimatisierung oder Heizung von Gebäuden.
Bei M2M-Projekten sind die Geräte beim Endkunden ja beispielsweise im Fahrzeug oder einem Gebäude verbaut. Das ermöglicht einem potenziellen Angreifer den physischen Zugriff auf das Gerät. Je nach Art der Netzwerkanbindung kann er den, unter Umständen unverschlüsselten, Netzwerkverkehr des Gerätes abhören und so an für ihn anderweitig verwertbare Informationen, wie Login-Daten, gelangen.
Bei M2M-Projekten muss außerdem sichergestellt sein, dass das Betriebssystem und die darauf installierte Software nicht kompromittiert wurden. Das ist anders als bei den meisten klassischen Projekten, bei denen nur ein sehr eingeschränkter Kreis an Administratoren physischen Zugriff auf die Server hat.
Eine weitere Besonderheit im Umfeld von M2M Security ist die Versorgung mit Updates. Einen Servicetechniker einzusetzen ist meistens zu kostspielig, also werden die Geräte automatisch mit Software Updates und Konfigurationsänderungen versorgt.
Wenn das Gerät aktiv, analog Microsoft Windows, nach Software-Updates sucht, muss auch sichergestellt sein, dass es nur Updates akzeptiert, die von einem autorisierten Herausgeber signiert wurden.
Einige Plattformen, wie z.B. die unserer Partner Axeda und ThingWorx, bieten mittlerweile die Möglichkeit, Konfigurationen für Software Updates zu verwalten.

Häufig sind Qualitätsmängel für später entstehende Sicherheitslöcher verantwortlich. Wie lassen sich solche Qualitätsrisiken, und daraus resultierende Schwachstellen, bereits bei der Konzeption minimieren?

Auf jeden Fall empfiehlt sich der Einsatz etablierter Standards für die Verschlüsselung und Signatur der Daten. Sie sollten Eigenimplementierungen auf jeden Fall vorgezogen werden, weil etablierte Algorithmen und deren Implementierungen im Vorfeld von vielen Experten unter die Lupe genommen wurden.
Allerdings zeigen die Meldungen aus der jüngsten Vergangenheit, wie z.B. ShellShock⁽²⁾ oder Heart-Bleed⁽³⁾, dass auch bereits seit Jahren oder sogar Jahrzehnten sehr verbreitete Software nicht vor Sicherheitslücken gefeit ist. Bei den standardisierten Anbietern ist aber zumindest mit einer zeitnahen Lösung durch die Maintainer zu rechnen. Das bringt aber wenig, wenn man keine Updates einspielen kann. Diese sollten wie gesagt bestenfalls ohne Zutun des Anwenders auf den Geräten eingespielt werden können. Das sollte bereits bei der Konzeption berücksichtigt werden.

Dem Endanwender fehlt meistens leider das Bewusstsein bzw. die Sensibilität für Sicherheitsaspekte, weil sie in der Regel kein explizites Verkaufsargument darstellen. Der Kunde sieht somit keinen Mehrwert – doch vielleicht ändert sich das jetzt durch anhaltende Diskussionen rund um IT-Sicherheit.

M2M Security ist in der Regel aufwändig und kostet Geld. Nach welchem Maßstab lässt sich das Kosten-Nutzen-Verhältnis bei M2M-Projekten abwägen?

Wie auch in der realen Welt kann man absolute Sicherheit nicht garantieren. Es geht vielmehr darum, die Sicherheitsrisiken auf ein, dem Schutzgrad der Daten entsprechendes Maß zu reduzieren. Sobald z.B. personenbezogene Daten im Spiel sind, aus denen sich eventuell sogar Verhaltens- und Bewegungsprofile der Benutzer ableiten lassen, wird das Thema Sicherheit immer wichtiger und kann auch rechtliche Konsequenzen in Verbindung mit entsprechend negativer Publicity nach sich ziehen. In konkreten Projekten führt man deshalb eine sogenannte Schutzbedarfsanalyse und eine Risikobewertung durch. Hier wird untersucht, welche Daten welchem Schutzgrad unterliegen.

Aber eins ist klar: Sicherheit ist umso aufwendiger, wenn sie erst nach der Implementierung, sozusagen On Top, in Angriff genommen wird. Dann muss im Zweifelsfall ein Großteil des Codes im Hinblick auf eventuelle Sicherheitslücken überarbeitet werden. Deshalb sollte man sich schon im Vorfeld intensiv mit M2M Security auseinander setzen.

Welche häufigen Fallstricke in Punkto M2M Security gibt es, wenn z.B. ein Remote Zugriff zu Servicezwecken auf entfernte Maschinen ermöglicht werden soll?

Bei M2M-Projekten ist meistens eine sehr große Anzahl von Geräten im Spiel, die zentral gewartet werden müssen. Grundlegend kann man hier zwei Ansatzmöglichkeiten zum Aufbau der Kommunikation unterscheiden:

1. Der Server initiiert die Verbindung: Dazu muss er die Adressen der Geräte kennen, die sich vorher z.B. an einem Verzeichnisdienst (dyndns) angemeldet haben.
2. Der Client (das Gerät) initiiert die Verbindung: Hier muss nur die Adresse des Servers bekannt sein und das Gerät holt sich die zu verarbeitenden Befehle ab (pull-Mechanismus).

Setzt man auf die erste Variante, dürfen die Namen, unter denen die Geräte angemeldet sind, natürlich nicht zu erraten sein.
Bei Variante 2 sollte man den zeitlichen Abstand gering genug wählen, um innerhalb weniger Sekunden oder Minuten eine Verbindung aufbauen zu können.

Da die M2M-Kommunikation über verschiedene Kommunikationstechniken, wie Bluetooth, WLAN, LAN, Mobilfunk etc. ablaufen kann, ist es wichtig, dass sämtliche Kommunikation verschlüsselt und signiert abläuft. So können Daten zwar mitgeschnitten, aber nicht verwertet oder manipuliert werden.
Generell empfiehlt sich auch der Einsatz von Zugriffs-Tokens oder SSL-Client-Zertifikaten.

Auch durch die vorher angesprochenen Softwareupdates und notwendigen Modifikationen im laufenden Betrieb können sich Fehler und Stabilitätsprobleme in ein Remote Diagnose System einschleichen. Gibt es dafür mittlerweile ein Patentrezept, wie die Systemstabilität kontinuierlich gewahrt werden kann?

Ein Patentrezept wäre schön, ist aber meines Wissens noch nicht gefunden. Bis dahin sollte man sich an etablierte Standards halten und auf ausgereifte, bestenfalls LTS (Long Time Support)-Versionen, von Mainstream-Softwarekomponenten verlassen. Die müssen auch nicht unbedingt die neuesten sein.

Um Stabilitätsproblemen zu begegnen ist es sinnvoll, automatische Rollback-Mechanismen einzubinden, falls eine Konfigurationsänderung fehlschlägt. Bei größeren Software Updates wird das aber bereits schwieriger, weil die meistens nicht so einfach zurückzurollen sind. Außerdem erzeugen diese Maßnahmen natürlich Aufwand und somit erhöhte Kosten.

Darüber hinaus ist es sinnvoll, die Verteilung von Updates zeitlich zu staffeln, um bei auftretenden Problemen eingreifen zu können. Hiermit verhindern auch große Konzerne wie Google, das gleich tausende Geräte betroffen sind.

Quellen:

[2] http://www.heise.de/mac-and-i/meldung/ShellShock-Standard-Unix-Shell-Bash-erlaubt-das-Ausfuehren-von-Schadcode-2403305.html