Am Puls von Kollege Roboter : Security-Sensorik für OT- und (I)IoT-SOCs

Von Johannes Wiele, München

Um die aktuellen Bewegungen im Markt für Sicherheitslösungen bei „Operational Technology“ (OT) zu verstehen, ist ein Blick auf die Situation in der klassischen IT hilfreich: Dort ist in den vergangenen Jahren der Stellenwert der Angriffserkennung gegenüber dem der präventiven Sicherheit stark gestiegen. Der Illusion, jeden Zugriff aufs eigene Netz und eigene Ressourcen im Vorfeld verhindern zu können, gibt sich kein ernsthaft agierendes Sicherheitsteam mehr hin (Assume-the-Breach-Prinzip).

Security-Operations-Center (SOC), die der Aufdeckung laufender Attacken auf klassische IT-Landschaften mit Büro- und Kommunikationsaufgaben dienen, können – grob betrachtet – zwischen zwei Ansätzen wählen:

• Auswertung der Logdaten von produktiven Systemen und Sicherheitswerkzeugen im Netz und Analyse auf sicherheitsrelevante Vorfälle
• Suche nach Spuren aktiver Angriffswerkzeuge oder schlicht nach Anomalien in der Netzkommunikation

Beide Modelle stehen in einem gewissen Wettbewerb, obwohl sie einander perfekt ergänzen. Vertreter des Netzwerkmonitorings und der Analyse von NetzMetadaten reklamieren für sich den Zugriff auf „Informationen aus erster Hand“, weil sie Anomalien in der Kommunikation oder Anzeichen für Malwareaktivitäten direkt erkennen, während bei der Auswertung von Logdaten ein Zwischenschritt notwendig sei – nämlich das Warten auf die Aktionserkennung durch die Einzelsysteme im Netz und die Aufbereitung ihrer Aha-Erlebnisse zu Logs.

Die Befürworter des klassischen Security-Information- und -Event-Management-(SIEM)-Ansatzes verweisen demgegenüber auf die teilweise höhere Aussagekraft der Logs und merken an, dass solche Informationen aufgrund von Compliance-Vorschriften ja ohnehin häufig aufbewahrt und analysiert werden müssten. Sie geben außerdem zu bedenken, dass sich die sicherheitstechnische „Zweitverwertung“ aus diesem Grund effektivitätshalber einfach anbiete. Auch dies ist richtig – und man beachte hier besonders den Punkt „Aussagekraft“: Denn hier liegt speziell für den OT-Bereich möglicherweise sogar ein Geschwindigkeitsvorteil der vermeintlich „um zwei Ecken“ laufenden Angriffswarnung via Log begründet! Dazu später mehr.

Anwender, deren Budget hoch genug ist oder deren Bedrohungslage dies erfordert, lassen im Bereich der Büro-IT den Streit der zwei Konzepte einfach Streit sein und kombinieren beide Modelle. Das funktioniert gut: So sehr nämlich die Anbieter aus der Netzwerkdaten-Analyse auf die Eignung ihrer Tools als alleinige SOC-Grundlage pochen mögen, so realistisch sind sie doch gleichzeitig hinsichtlich der Akzeptanz dieser Idee und bereiten ihre Systeme deshalb sehr wohl darauf vor, ihre Erkenntnisse auch (aus zweiter Reihe) der Korrelationslogik von SIEM-Systemen als zusätzliche Informationsquelle zur Verfügung zu stellen.

OT erzwingt Passivität

In der OT-Welt ist bisher die passive Netzwerkanalyse mit dem Ziel der Anomalie-Detektion der weiter verbreitete Ansatz – besser gesagt: der einzig verbreitete. Die hier engagierten Anbieter haben oft Erfahrung aus dem militärischen Bereich und können sich auf exzellente Kenntnisse der im Industrieumfeld verwendeten Protokolle berufen.

Ihre Fokussierung auf das industrielle Netzgeschehen ergibt durchaus Sinn: Erst einmal liefern die meisten der heute aktiven, über einen Zeitraum von bis zu 30 oder 40 Jahren laufenden Maschinen nicht in dem Maße verwertbare Log-Dateien, wie es typische IT-Systeme tun. Während sich der Output von IT-Systemen mit Parser-Auswertung und „Normalisierung“ inzwischen mit einigermaßen vertretbarem Aufwand für SIEM-Systeme konsumierbar machen lässt, ist dies bei Produktionsanlagen nicht so einfach der Fall – zumindest nicht ohne aktive Mithilfe der jeweiligen Maschinenbauer und Steuerungs-Entwickler. Oft ist es zudem weder gewünscht noch praktikabel, die Betriebssysteme von Maschinensteuerungen mit neuen Aufgaben zu betrauen.

Dafür stellt sich das Kommunikationsgeschehen in den Netzen von Produktionssystemen weitaus vorhersagbarer und gleichbleibender dar als das eines Netzes, in dem menschliche Anwender kreativ agieren. Anomalie-Erkennung hat deshalb in der OT oder der Welt des (industriellen) Internet of Things (IIoT) oder auch der Industrial Control-Systems (ICS) eine viel höhere Trefferquote und benötigt weitaus kürzere Phasen zur Erhebung des normalen Geschehens (Lernmodus). Dies gilt besonders dann, wenn Anlagen über einen längeren Zeitraum hinweg immer das gleiche Produkt herstellen. In diesem Fall werden während des Normalbetriebs in Echtzeit immer wieder die gleichen Informationen und „Trigger“ zwischen den Komponenten ausgetauscht – jede Abweichung vom gewohnten Rhythmus weist mit einiger Wahrscheinlichkeit auf eine Störung oder zumindest auf einen untersuchenswerten Fall hin. Aber selbst dann, wenn auf der gleichen Anlage mehrere Produktvarianten entstehen oder wenn KI-gesteuerte Roboter erste eigene Entscheidungen über die beste Abwicklung übergebener Aufgaben treffen können, bleibt der Spielraum der Maschinen fast immer überschaubar – ganz anders als in einem Büro, in dem man von Zeit zu Zeit auf gänzlich neue Ideen kommt oder bewusst experimentiert.

Eintönigkeit erleichtert Anomalie-Erkennung

Vielleicht lässt sich als Extremfall eine Fabrik denken, in der hochentwickelte 3D-Drucker vollkommen individuelle, von Endanwendern bestellte Werkstücke produzieren, die direkt über ein Eingabeportal im Web angefordert werden. Ansätze in dieser Richtung gibt es schon: Spezialisten reproduzieren auf diese Weise verschlissene frühe Plastik-Ersatzteile für Oldtimer-Fahrzeuge. Selbst in solch einem Fall dürfte es aber möglich sein, auf der Basis fester Schwellenwerte für die Aktionsbereiche der Produktionsmaschinerie „riskante“ Aktionen relativ sauber von „unverdächtigen“ zu unterscheiden.

Insgesamt trifft es also zu, dass passive Netzwerkanalyse die im OT-Bereich am schnellsten dienstbereite Technik zur Angriffserkennung darstellt und dieses Modell tatsächlich wertvollen SOC-Input liefert. Überdies muss man nicht in die Maschinen mit ihrem oft heiklen Echtzeitverhalten und die teils fast schon antike Technik der Steuerungen eingreifen.

Ein Roboter, der während der Produktion plötzlich in einen Lern- oder Wartungsmodus versetzt wird, sollte dies selbst unverzüglich und verständlich melden – denn hier ist nicht nur die Produktion gefährdet, sondern unerwartete Bewegungen bedeuten auch ein Risiko für Menschen in seiner Nähe.

Tatsächlich auftretende Anomalien dürfen grundsätzlich als ernst zu nehmender Anfangsverdacht für eine Kompromittierung gelten, und es gibt in diesem Zusammenhang nicht so viele False Positives wie im IT-Segment. Hinzu kommt, dass sich die Erkennungstechnik mittels „Security-Intelligence“ so trimmen lässt, dass sie anderswo bekannt gewordene Kommunikationsmuster bereits analysierter OT- oder IoT-Malware direkt erkennt.

Der Alptraum gekaperter Roboter

Bestimmte Geschehnisse erkennt eine passive Netzwerküberwachung allerdings nicht unbedingt auf Anhieb – oder zumindest nicht in einer Weise, bei der von vornherein auch der Kontext und das Risikopotenzial dieser Ereignisse klar würden. Man nehme beispielsweise an, ein Roboter würde während der laufenden Produktion unerwartet in den Lernmodus umgestellt. Das könnte durch einen manuellen Eingriff oder über einen kompromittierten Fernwartungskanal geschehen, also gegebenenfalls auch über Zugriffswege, die der implementierten Industrie-Netz-Überwachung nicht unterliegen.

Je nach System würde der Anomalie-Erkennung dann wahr scheinlich dennoch bald eine Störung auffallen, aber sie könnte nicht unbedingt sofort die Tragweite des Ereignisses ermitteln. Das Risikopotenzial ist hier aber die zentrale Entscheidungsgrundlage für die Reaktion: Denn in diesem Fall sind gegebenenfalls nicht nur Produktionsergebnisse gefährdet, sondern es besteht vielleicht auch akute Verletzungsgefahr für Menschen, die in der Reichweite der konkreten Produktionsanlage arbeiten.

Interessant ist in diesem Zusammenhang, dass die Geschichte vom Roboter, der infolge perfider Manipulationen oder unvorhergesehener Schlussfolgerungen seine Umgebung gefährdet, wohl fast so alt ist wie die Digitalisierung der industriellen Produktion selbst. Hier lauert tatsächlich eine von Anfang an fundamentale Problematik der Sicherheit von Produktionsabläufen, die in gewissem Maße von künstlicher Intelligenz gesteuert werden.

Eine kleine Kostprobe aus der Science-Fiction kann das Problem gut illustrieren und auf erfreulich unterhaltsame Weise verdeutlichen, welche Rolle in diesem Zusammenhang Monitoringsysteme und „Meldepflichten“ spielen. In unserer Beispielgeschichte trifft zuerst ein unspezifischer Anomalie-Hinweis ein: Commodore Ruyther, Kommandant des Raumfrachters Sikh 12 und ein alter Bekannter […] erzählt McLane im Vertrauen, dass auf dem Planetoiden Pallas, dessen Erz er normalerweise transportiert, etwas nicht stimme. Er erhalte in letzter Zeit immer nur Abraum anstelle von Erz.

Dieser Merkwürdigkeit halber startet im weiteren Verlauf ein Raumschiff nach Pallas, um dem Problem auf den Grund zu gehen. Fans wissen wahrscheinlich schon welches und schwelgen vermutlich sofort in der Erinnerung futuristischer Steuerhebel aus recycelten Bügeleisen und umgewidmeten Badezimmerarmaturen.

Die […] Crew landet auf [dem Planeten] Pallas und macht sich auf die Suche nach den Kolonisten. In den unterirdischen Schächten werden sie von zwei bewaffneten Arbeitsrobotern des Typs Alpha Ce Fe überrascht, entwaffnet und in die Stollen gesperrt. […] Auf Pallas erkennt man, dass die Roboter durch einen Widerspruch in den Robotergesetzen „umprogrammiert“ worden sind. Durch eine List gelingt es Jagellovsk und McLane, zwei Roboter wieder normal zu programmieren und zu entwaffnen. Mit den Waffen schalten sie die restlichen Roboter aus […]

Die hier zitierte Stelle ist der Wikipedia-Inhaltsangabe zur deutschen Weltraum-Serie „Raumpatrouille Orion“ entnommen (https://de.wikipedia.org/wiki/Raumpatrouille_%E2%80%93_Die_phantastischen_Abenteuer_des_Raumschiffes_Orion, CC-BY-SA-3.0). Die Erstausstrahlung der Folge „Hüter des Gesetzes“ war am 15. Oktober 1966 – das Phänomen des Roboters, in dessen Handlungsvorgaben ein nicht-autorisierter Fremder oder eine komplexe Form von Störung eingreift, hat offenbar auch damals schon die Gemüter bewegt.

Allerdings wirkt das Konzept der Risikominimierung, das der Handlung und dem darin aufgehobenen Roboter-Entwurf zugrunde liegt, heute eher merkwürdig. Die Autoren der Serie haben nicht im Entferntesten an die heutige Dimension allgegenwärtiger Vernetzung und umfassenden Security-Monitorings denken können – sonst hätten sie den damals noch vollständig ihrer Einbildungskraft entsprungenen, autark operierenden Rohstofffördermaschinen statt eines abstrakten Robotergesetzes wohl eher eine deterministische Mitteilungspflicht über Manipulationsversuche und Änderungen an der grundlegenden Programmierung mit auf den Weg gegeben.

Kurioserweise hält sich die von Isaac Asimov bereits 1942 beschriebene Idee vom Robotergesetz als probate Kontrollinstanz für eigenständig agierende künstliche Intelligenz bis heute in der Zukunfts-Literatur- und -Filmwelt – man denke nur an Commander Data aus der Serie „Raumschiff Enterprise – Das nächste Jahrhundert“ (1987 bis 1994) oder den Kinofilm „I, Robot“, der 2004 über fünfzig Jahre nach Asimovs gleichnamiger Story erschienen ist. Und es gibt noch fast unüberschaubar viele weitere Beispiele. Der Angst vor drohendem Kontrollverlust gegenüber einem übermächtig „intelligenten“ oder starken Automaten scheint der Mensch unumstößliche, tief verankerte Gebote entgegensetzen zu müssen.

Man darf darüber spekulieren, warum die Menschheit bei der „Zivilisierung“ von Robotern noch immer lieber an „heilige Gebote“ denkt als an die längst alltäglichen (und erfolgreichen) Konzepte von „Gesetzgebung“ und „Kommunikation“. Immerhin „reden“ moderne Maschinen doch auch schon geraume Zeit lang verständlich mit ihren Kontrolleuren an Leitständen und dem Wartungspersonal, das per Remote-Control agiert.

Vielleicht steckt dahinter tatsächlich das Faktum, dass in der Sprache und der rudimentären KI von Robotern und Produktionsanlagen dass Thema Sicherheit noch eher schwach verankert ist. Man weiß heute, das Büro-IT über Sensorik und eine Art Immunsystem gegen Übergriffe von außen verfügt. In die OT hingegen muss man mangels integrierter Cybersicherheits-Fühler noch mühsam von außen hineinlauschen, um Attacken aufzudecken. Der überschaubaren Community von Spezialisten für kombinierte OT-/IT-Sicherheit ist das durchaus ein Dorn im Auge. Aber nun scheint es, als käme praktikable Abhilfe in Sicht.

Meldepflichten für Maschinen

Bei Produktionsanlagen ist die Integrität des Ablaufs erwünschter Prozesse das primäre Schutzziel. Varianzgrenzen und zugehörige Schwellwerte dürfen deshalb nicht manipuliert werden. Jedes sinnvolle Risikoassessment muss feindliche oder einfach unkontrollierbare Eingriffe in die vorgegebenen Abläufe einer Produktion oder die Manipulation von Aktions-Rahmenwerten von Produktionskomponenten als primär abzuwendende Gefahr einstufen. Deshalb kann es nur sinnvoll sein, wenn ein Security-Team festlegen kann, von welchen Parameter-Änderungen an einer Maschine es immer sofort erfahren will.

Virulent ist diese Thematik geworden, seit die Digitalisierung die traditionelle Abschottung der Produktionsanlagen gegen Eingriffe von außerhalb der Produktionsstätten radikal verringert. Immer mehr Schnittstellen zur Office-IT, zu Intranets und zum Internet haben immer mehr schlechter kontrollierbare Einflussnahmen von außen zur Folge. Gleichzeitig ist es aber immer noch möglich, den meisten Maschinen bestimmte Vorgänge per fester Programmierung zur Pflicht zu machen.

Wenn sie denn direkt übermittelt werden kann, ist die Information: „Schweißroboter 16 an Straße 8 meldet die Umschaltung in den Lernmodus“ viel unmittelbarer, präziser und für eine sofortige Risikoeinschätzung wertvoller als eine Meldung zu „modifizierten Kommunikationspaketen im Netz von Straße 8“, die erst sekundär mit Kontextinformationen angereichert werden muss, die dann (hoffentlich) auf den fraglichen Roboter hinweisen. Klar, auch diese Korrelation kann schnell erfolgen – aber nur dann, wenn vorab auch das entsprechende Interpretationsspektrum im System verankert wird, wozu Anbieter und Kunde aktiv werden und Ressourcen freistellen müssen. Der Grad der Verfügbarkeit von Kontext-Informationen in Angriffsfall ist ein Wert, der oft genug darüber entscheidet, ob eine Cyber-Attacke noch abgewehrt werden kann oder nicht (vgl. [2]).

Konkretes Projekt für bessere Zusammenarbeit

Pressemitteilungen, in denen sich Hersteller als „Marktführer“ oder „innovativste Anbieter“ in ihrem Markt präsentieren, sollte man zweifellos immer kritisch hinterfragen – oft steckt hinter einer derart propagierten Meisterleistung bei näherem Hinsehen weit weniger, als es die Akteure glauben machen wollen. Eine im Oktober 2020 lancierte Nachricht scheint allerdings im hier diskutierten Kontext tatsächlich Beachtung zu verdienen. ABB und IBM präsentieren sich darin als Pioniere der Integration von Produktionsmaschinerie und SOC: ABB-Steuerungen – und zwar laut Auskunft der beteiligten Firmen auch ältere Exemplare [1] – sollen mit der Fähigkeit ausgestattet werden, sicherheitsrelevante Meldungen direkt ans IBM-SIEM-System QRadar abzusetzen. Diese Technik läuft unter dem Titel „OT Security Event Monitoring Service“.

Das ist zunächst nicht zuletzt deswegen interessant, als das wegen seiner leicht angestaubten Benutzeroberfläche und einer leidigen „Events-per-Second“-Kostenstruktur zuweilen als Dinosaurierer abgestempelte QRadar mittels Plug-in-Technik auch eine Integration von OT-Netzwerk- und Protokoll-Überwachungssystemen wie CyberX, Nozomi oder Rhebo ermöglicht – letzteres erfreulicherweise beheimatet in Deutschland und damit im europäischen Datenschutzraum.

Die beiden Erkennungstechniken machen dann zusammen ungemein treffsichere IT/OT-UseCases und -Angriffskorrelationen möglich. Sie ermöglichen außerdem auf Anwenderseite den schrittweisen Einstieg in eine langfristig immer effizientere Erkennung von Angriffen auf spezifische OT-Umgebungen. Nimmt man noch hinzu, dass das zuweilen als sekundär gescholtene IBM-Add-on Watson zu OT-spezifischen Meldungen im SOC ob der mitgelieferten Kontextinformation (vgl. [2]) auch ohne Training Internet-Quellen zur Abhilfe erschließen kann, könnte das so ermöglichte Team „Maschine/SIEM“ der Sicherheit im OT-Bereich tatsächlich mächtig Vorschub leisten.

Veränderung braucht Kooperation

Andere Akteure im Markt – als willkürliche Beispiele mögen hier Splunk als flexibles, Data-Lake-orientiertes SIEM- und Log-Auswertungssystem auf der einen Seite und Siemens als Maschinenbauer auf der anderen Seite dienen – sind gut beraten, sich die genannten Unternehmen zum Vorbild zu nehmen und ebenfalls die Fühler zueinander auszustrecken. Wer „Siemens“ liest und an die Mitbewerber dieses Unternehmens denkt, weiß, welche Tragweite eine solche Idee hätte: Es wird zukünftig dringend notwendig sein, zum Beispiel auch Medizintechnik im IoT mit den beschriebenen direkten Schnittstellen zu Sicherheits-Monitoring-Tools auszustatten.

Lobenswert ist, dass die IBM/ABB-Zusammenarbeit laut Pressemitteilung unter den Prämissen „Referenzarchitektur“ und „offene Plattformen“ steht. Ist dieses Statement ernst gemeint, können bald hoffentlich auch Nicht-IBM- und Nicht-ABB-Kunden von dieser Entwicklung profitieren – was umso erfreulicher wäre, als viele Akteure im Maschinenbau-Markt nicht eben zu übertriebener Agilität bei Reaktionen auf Marktanforderungen außerhalb ihrer selbst definierten Kernkompetenz neigen.

Tatsächlich dürfte einiger Aufwand in der Ausstattung von ABB-Steuerungen mit einer Art Cybersecurity-Sprachmodul stecken, das für den QRadar-Parser verständliche Statusinformationen produziert. SIEM-Profis wissen, wie langwierig der Bau entsprechender Konnektoren auch bei sogenannter Legacy-Technik in der IT sein kann. Dem Modul neben dem QRadar-Dialekt dann auch noch „Splunk“, „LogRhythm“ und so weiter beizubringen, bewegt sich allerdings eher auf dem Niveau von Feinarbeit. Interessant zu wissen wäre auch, ob der ABB-Output nicht jetzt schon Daten liefert, die sich in SIEM-Systemen auf der Basis des ELK-Stacks (Elasticsearch, Logstash und Kibana) auswerten lassen. Dies würde Möglichkeiten eröffnen, securityrelevante Kommunikation von Produktionsanlagen sogar in größeren, businessorientierten Zusammenhängen mit einem einzigen, Data-Lake-gestützten System auszuwerten.

Fazit

Wer in Unternehmen des produzierenden Gewerbes in Zukunft entweder für OT/(I)IoT-Security, für IT-Security oder für beides zuständig ist, sollte beim Aufbau von SOC-Strukturen für beide Bereiche einen genauen Blick darauf werfen, für welche Erkennungstechniken die Werkzeuge bereits vorbereitet sind, die im Zentrum des SOCs zum Zuge kommen sollen – Zukunftssicherheit und Ausbaufähigkeit sind hier zentrale Merkmale.

Und ein wenig Druck auf die Maschinenbauer kann auch nicht schaden: Denn wie sie das Thema Cyber-Security zukünftig in ihren Prozesssteuerungen verankern, könnte eine echte Entscheidungsgrundlage für den nächsten Maschinenersatz sein – auch wenn der erst nach 30 oder 40 Jahren Laufzeit fällig wird. ■

Dr. Johannes Wiele (johannes@wiele.com) ist freier Autor sowie GDD-geprüfter Datenschutzbeauftragter und arbeitet als Senior-Manager in der Cybersecurity-Beratung.

Literatur

[1] Asea Brown Boveri (ABB) Ltd., ABB und IBM stärken Cybersicherheit für Industrieunternehmen, Prozessleitsysteme von ABB können sich mit IBM-Security-Plattform zur Erkennung digitaler Bedrohungen verbinden, Medienmitteilung, Oktober 2020, https://new.abb.com/news/de/detail/69239/abb-und-ibm-starken-cybersicherheit-fur-industrieunternehmen

[2] Bettina Weßelmann und Johannes Wiele, Grüße von der langen Bank – Dauerbaustellen der Security (2), Haie fischt man nicht im Trüben, <kes> 2016#4, S. 26