SSV Software Systems

Zeitenwende in der Bedrohungslage

17. August 2022, 15:24 Uhr | Klaus-Dieter Walter

Wer in der heutigen Zeit eine neue IoT-Anwendung plant, sollte unbedingt auch die möglichen Cyberrisiken sorgfältig analysieren und Gegenmaßnahmen entwerfen. Vielfach sind solche Analysen auch nachträglich sinnvoll.

Mit einer immer weiter fortschreitenden Vernetzung steigen seit Jahren auch die Risiken bezüglich größerer Cyberangriffe – mit erheblichen Auswirkungen. Kommt es darüber hinaus noch zu kriegerischen Auseinandersetzungen, wie derzeit im östlichen Europa, erreicht die Bedrohungslage ein Niveau, welches das eigene Handeln auf jeden Fall beeinflussen sollte. Teilweise erfordert die aktuelle Situation zudem einen neuen Blickwinkel auf vernetzte Anwendungen und zukünftige Entwicklungsvorhaben.

Neue Sichtweisen

Dass man eine satellitenbasierte Internetverbindung auch für IoT-Applikationen nutzen kann, ist nicht neu. Bisher waren es aber lediglich Kostenaspekte, die den Praxiseinsatz teilweise verhindert haben. Nun wird deutlich, dass bestimmte Staaten solche drahtlosen Internetzugänge aus unterschiedlichen Gründen als erhebliche Bedrohung für die eigene Sicherheit einstufen. Schließlich besitzt diese Kommunikationstechnik einen „Dual-Use-Charakter“. Man kann damit nicht nur ortsungebunden eine beliebige Webseite zur Informationsbeschaffung aufrufen, mit einem satellitenbasierten Internetzugang lassen sich auch relativ einfach „abhörsichere“ Daten von verschiedenen Standorten aus über eine Ende-zu-Ende-Verbindung an eine Sammelstelle verschicken, um beispielsweise dezentrale Sensorikanwendungen für militärische Zwecke zu realisieren.

Auch die Kommunikation zwischen mobilen Truppenteilen oder Drohnen und Leitstelle ist schnell, einfach und aus militärischer Sicht sogar außerordentlich preiswert umsetzbar. Chinas Militär prüft daher sogar die Zerstörung des Starlink-Satelliteninternets von Elon Musks SpaceX (wie in der Tagespresse Ende Mai 2022 berichtet wurde). Die damit verbundenen Risiken möglicher Kollateralschäden für eigene IoT-Anwendungen sind auf jeden Fall zu bewerten.

Auch hinsichtlich potenzieller Cyberangreifer hat sich einiges getan: Im Internet wird offen für die „IT Army of Ukraine“ geworben. Jeder, der über ausreichende Spezialkenntnisse verfügt, kann sich dieser Cyber-Guerrilla-Gruppe anschließen, um etwa aus dem Homeoffice beliebige virtuelle Ziele in anderen Ländern zu attackieren. Koordiniert werden die Attacken über die Telegram-Messenger-App. Bisher wurden aber wohl nur einfache DDoS-Angriffe ausgeführt. Es bleibt zu hoffen, dass die Idee nicht zu einem „Cyberangriff-as-a-Service“-Angebot führt. Entsprechende Werkzeuge zur Gefahrenanalyse gehören zukünftig aber in jeden Entwicklerbaukasten.

Schwachstellen- und Risikoanalyse

Eine etablierte Methode aus dem Umfeld von Maschinen und Anlagen ist die Fehlermöglichkeits- und Einflussanalyse (FMEA, Englisch: Failure Mode and Effects Analysis). Grundsätzlich ist eine FMEA auch für die Cyber Security von IoT-Anwendungen und vernetzten Automatisierungslösungen anwendbar. Im Internet findet man dazu zahlreiche Informationsquellen. Bei einer Cyber Security FMEA müssen aber die einzelnen Risikobereiche Hardware, Software, Netzwerkverbindungen sowie Cloud über sehr erfahrene Experten im Team vertreten sein. Auf jeden Fall sollte eine Threat-Modellierung (Security Threat Modeling) an Hand einer detaillierten Anwendungsstruktur erfolgen. Hinsichtlich möglicher Risiken liefert beispielsweise das Microsoft-STRIDE-Modeling-Werkzeug eine Hilfestellung. Bei einer solchen Analyse kann man sich darüber hinaus am Datenfluss einer IoT-Applikation orientieren – also vom Sensor über die Datenanalyse und die automatisierte Entscheidungsfindung bis zur daraus abgeleiteten Handlung (siehe Bild 1). Hinsichtlich der Entdeckungswahrscheinlichkeiten und Prioritäten ist zu beachten, dass man es mit einem recht dynamischen Umfeld zu tun hat; die Risiken einer Cloudverbindung können sich zum Beispiel im Laufe der Zeit verändern.

Konzertierter Methodeneinsatz

Ein wirkungsvolles Konzept, um die Erkenntnisse systematischer Schwachstellen- und Risikoanalyen umzusetzen, sind sogenannte DevOps. Hinter diesem aus „Dev“ (Development, Entwicklung) und „Ops“ (Operations, Vorgänge) zusammengesetzten Begriff verbirgt sich eine sehr effektive Vorgehensweise zur Softwareentwicklung und Wartung. DevOps vereinen Menschen, Methoden, Prozesse und Technologien, um kontinuierlich hochwertige Produkte und Lösungen zu schaffen und in der Praxis zu betreiben. Die acht typischen Dev-Ops-Phasen werden vielfach als Endlosschleife dargestellt (rechts im Bild 2), die vom zuständigen Produktmanagement, dem Entwicklerteam und den Anwendungsverantwortlichen als Prozesskette immer wieder durchlaufen werden. In diesem Konstrukt ist jeweils eine CI- (Continuous Integration, Softwarecodierungs- und Änderungsprozess) und CD- (Continuous Delivery, Software-Auslieferungsprozess) Aktivitäten-Pipeline enthalten. Alle anfallenden Aufgaben werden dabei von einem Entwickler- und einem Anwendungs-team bearbeitet.

DevOps wurden in der IT-Welt entwickelt und werden dort auch seit vielen Jahren in unzähligen Anwendungen eingesetzt. Die DevOps-Methoden lassen sich unter bestimmten Voraussetzungen auch auf die vernetzten Embedded Systeme von IoT-Baugruppen sowie die dazugehörenden Cloud-basierten Softwarefunktionen anwenden. Um damit allerdings die Ausfallprobleme von Satellitenmodems und Kreditkartenzahlungsterminals zu verhindern (siehe IoT-Hotspot in der Ausgabe 5/6-2022), müssen die Baugruppen und Anwendungen bestimmte Voraussetzungen erfüllen (Bild 2).

Jede IoT-Baugruppe sollte zwei Kommunikationsverbindungen besitzen, jeweils einen Default Link und einen Out-of-Band- (OoB) Link. Als Firmware-Speicher werden zwei voneinander unabhängige Flash-Speicherbereiche (Firmware Image A, Firmware Image B) genutzt, die durch eine spezielle Schreibschutz-Hardware (beispielsweise ein Authenticated Write Latch) geschützt werden. Das Firmware Image A dient zum Beispiel für den Normalbetrieb per Default Link, Firmware Image B ermöglicht bei Problemen ein Recovery über den OoB Link. Ein spezieller kryptografischer Watchdog-Zeitgeber (AWDT = Authenticated Watchdog Timer) überwacht die Default-Link-Funktion. Im Fehlerfall wird über die A/B-Funktionalität die Recovery-Firmware aktiviert. Sowohl die Firmware-Varianten der IoT-Baugruppen als auch die Softwarefunktionen der Cloudservices werden über DevOps permanent weiterentwickelt. Durch die zu einem DevOps gehörenden Monitoring-Aufgaben existiert darüber hinaus eine weitere Überwachungsebene, die auch Cloudseitig ein OoB-Recovery auslösen kann.

Lohnender Mehraufwand

Mit systematischen Schwachstellen- und Risikoanalysen sowie dem Zusammenspiel einiger spezieller Hard- und Softwarefunktionen plus DevOps lässt sich trotz der aktuellen Bedrohungslage ein sehr robustes Systemverhalten für IoT-Baugruppen und Anwendungen realisieren. Dadurch entsteht zwar ein gewisser Mehraufwand mit Auswirkungen auf die Stück- und Betriebskosten. Dieser Aufwand ist für Applikationen im Bereich kritischer Infrastruktur (z.B. dezentrale Energieanlagen) aber auf jeden Fall gerechtfertigt, da sich die Anwendungsverfügbarkeit auch bei einer weiterhin zunehmenden Cybergefahrenlage verbessert.