Erhebliche Aufregung droht Anbietern und Nutzern jeglicher Art von „industrieller IT“. Sei der betroffene Sektor nun Internet of Things (IoT), Industrial Control Systems (ICS) oder auch Operational Technology (OT) genannt, es könnten bedrohliche Zeiten auf die Betreiber solcher Technik zukommen.
Die Bedrohung wird durch eine ganze Reihe von Sicherheitslücken in „ICS-Geräten“ verursacht. Betroffen sind Geräte jeder Größe und Kritikalität, angefangen von kleinen Messgeräten bis hin zu Steuerungen großer Anlagen.
Die ersten öffentlichen Hinweise sind in einer Veröffentlichung israelischer IT-Sicherheitsexperten von Juni 2020 enthalten. Sie haben in einer Softwarekomponente der Firma Treck, die von vielen Anbietern in verschiedenste ICS-Produkte quer über alle Branchen und Verwendungen eingebaut wurde – und auch immer noch wird – insgesamt 19 teils gravierende Fehler entdeckt. Sinnigerweise haben die Entdecker der Schwachstellen diese „Fehlersuite“ „ripple20“ getauft.
Alle Fehler sind im sogenannten TCP/IP-Stack enthalten, also in der Software, die aus Bitfolgen auf dem Netzwerk Datenstrukturen erzeugt, die dann für irgendwelche produktspezifischen ICS Anwendungen verwendbar sind. Das Problem beim Treck TCP/IP Stack ist, dass diese Software in eine minimalistische Softwareumgebung eingebettet ist. Minimalistisch heißt an dieser Stelle, dass dieser Netzwerkstack kein Bestandteil eines Windows-RT oder einer minimalen-Linux-Umgebung ist, sondern bestenfalls an RTOS, einem auf Basisfunktionen beschränkten-Echtzeit-Betriebssystem, angedockt ist. Folglich gibt es darin keine interne Firewall, keine Filterung und in vielen Fällen nicht einmal die Möglichkeit Patches einzubringen. Betroffen sind weltweit nach Einschätzung verschiedener offizieller Stellen Millionen bis Milliarden von Geräten.
Wohlgemerkt hat der Softwarehersteller Treck die Fehler in der aktuellen Fassung korrigiert und auch Korrekturen für all die Fehler in älteren Versionen bereitgestellt. Ob jedoch die Treck-Kunden, also die Unternehmen, die diese Software in ihren Produkten verbaut haben, die Fehlerkorrekturen auch für das jeweilige Produkt bereitstellen werden oder bereitstellen können, ist unklar. Betroffene Hersteller sind z. B. Schneider Electric/APC, HP, Miele, vermutlich auch Honeywell, BAE usw. Eine stetig wachsende Liste führt zum Beispiel die US-Behörde Cybersecurity and Infrastructure Security Agency (CISA): https://us-cert.cisa.gov/ics/advisories/icsa-20-168-01
Die Entdecker der Sicherheitslücken, die mit Treck seit Monaten in Verbindung stehen, haben angekündigt, weitere Details zu den Lücken auf einem Kongress im Spätsommer zu veröffentlichen. Es ist bereits jetzt abzusehen, dass nach einer genaueren Beschreibung der gefundenen Sicherheitslücken massenhaft Angriffsversuche auf Geräte, die betroffen sein könnten, erfolgen werden.
Handlungsbedarf
Die Mindestanforderung aus dieser Lage ist die Umsetzung oder Kontrolle mehrerer für den ICS-Einsatz grundlegender Maßnahmen:
1. Es muss klar sein, ob und an welcher Stelle in den betreuten oder betriebenen Netzen ICT-Geräte dauerhaft oder gelegentlich aus dem Internet erreichbar sind. Wenn die Systeme dauerhaft durch eine korrekt eingestellte Firewall geschützt sind, ist viel erreicht.
2. Es muss klar sein, wer auf welchem Weg einen Fernzugriffs- oder Fernwartungs-Zugang auf ICS-Geräte erhalten kann. Die Sicherheit von Fernwartungszugängen muss geprüft werden. Ein durch Windows-RDP möglicher Fernzugriff ist häufig eine durchaus überwindbare Hürde vor einem ICS-Netz voller Schwachstellen. Besser ist der Einsatz von Fernwartungslösungen wie Secomea (www.secomea.com/de) oder der Genua genubox (www.genua.de/loesungen/absicherung-fernwartung-von-maschinen-und-it-systemen.html).
3. Es muss eine Aufstellung von ICS-Geräten mit möglichst genauer Spezifikation des Geräts, des Gerätetyps, der Firmware-Version oder des Softwarestandes angelegt werden. Nur so lässt sich bestimmen, ob bzw. wo Sicherheitspatches machbar sind.
4. Wenn Patches nicht möglich sind, muss geprüft werden, ob durch eine weitere Segmentierung des Netzes eine Absicherung von kritischen Geräten erreicht werden kann. Um schwierige Konfigurationsänderungen zu vermeiden, sollte der Einsatz von „Bridging Firewalls“ geprüft werden. Sie können Geräte abschotten, ohne die Netz-Architektur oder auch nur IP-Adressen ändern zu müssen.
5. Da nach heutigem Kenntnisstand eine Reihe der ripple20-Schwachstellen auf „trickreichem“ Netzverkehr wie IP-Tunneling basiert, scheint eine sorgfältige Filterung auf den Firewalls eine wirksame Vorsorge zu sein. Wenn eine restriktiv eingestellte Firewall nur den Datenverkehr passieren lässt, der unverzichtbar im „OT-Netz“ ist, wird nach aktuellem Kenntnisstand ein großer Teil der möglichen Angriffsmethoden abgeblockt.
