Das falsche Bild vom gehackten Roboter

Stellen Sie sich einen Roboterarm vor, der plötzlich unkontrolliert durch die Halle schwingt, während eine rote Warnleuchte blinkt und jemand hektisch nach dem Not-Aus greift. Genau dieses Bild prägt viele Sicherheitsgespräche, die Sie als OT- oder Produktionssicherheitsverantwortliche eines Industrieunternehmens mit vernetzter Robotik führen – Roboterzellen, AMR-Flotten (autonome mobile Roboter), Vision-Systeme, ein zentraler Flottenmanager. Es ist ein wirkungsvolles Bild aus dem Kino, aber ein irreführendes für die eigene Risikoeinschätzung.

Der physische Not-Halt an der einzelnen Maschine ist und bleibt die verlässlichste Sicherung gegen genau diese Art von Bewegungsgefahr; ein eigener Beitrag zur Sicherheit autonomer Roboter im Bestand ordnet ihn technisch ein, und diese Einordnung wird hier nicht relativiert.

Was Industrieroboter und Cobots technisch unterscheidet und wo sie heute eingesetzt werden, beantwortet ein eigener Beitrag zu Industrierobotern und Cobots – dieser Beitrag hier fragt etwas anderes: nicht, was die Maschine kann, sondern was um sie herum verwundbar ist, wenn jemand sie gar nicht bewegen will.

Denn wer eine Fabrik kompromittiert, hat selten ein Interesse daran, dass es jemand sofort merkt. Ein Roboterarm, der sichtbar außer Kontrolle gerät, löst binnen Sekunden einen Alarm aus, zieht die Werkleitung herbei und beendet den Zugriff, bevor er sich lohnt. Ein Flottenmanager, der Transportaufträge unauffällig umsortiert, oder ein Servicekonto, das über Wochen Prozessdaten abzieht, tut genau das nicht – und deshalb sind diese Ziele für einen Angreifer interessanter als die Maschine selbst.

Die praktische Konsequenz für Ihre eigene Angriffsflächenanalyse: Wer nur die Roboterzelle betrachtet, blendet die Systeme aus, die tatsächlich mehr wert sind – Steuerungsketten, Produktionsdaten und die digitale Identität, die entscheidet, wie viel reale Wirkung ein einzelnes Konto überhaupt auslösen darf.

Die Steuerkette ist eine Vertrauenskette

Eine Roboterzelle bekommt ihre Aufträge selten aus dem Nichts. Ein Manufacturing-Execution-System übergibt einen Fertigungsauftrag, ein Flottenmanager weist einem fahrerlosen Transportfahrzeug eine Route zu, eine Vision-Pipeline liefert die Koordinaten für den nächsten Griff. Jede dieser Übergaben ist ein Vertrauensverhältnis: Die Zelle geht davon aus, dass der Befehl, der bei ihr ankommt, tatsächlich von der Stelle stammt, die er zu sein behauptet, und tatsächlich zu dem passt, was gerade produziert werden soll.

MITRE ATT&CK ICS führt diese drei Angriffsfolgen unter eigenen Technik-Kennungen — T0829, T0831 und T0882 — nicht nur als vage Kategorien: Loss of View, wenn Sie den tatsächlichen Anlagenzustand nicht mehr sehen; Manipulation of Control, wenn ein Sollwert oder Prozessparameter unbemerkt verändert wird; Theft of Operational Information, wenn Prozesswissen abfließt. Was die drei verbindet, ist genau das Muster aus dem vorigen Abschnitt: Keine davon erfordert, dass eine Maschine sichtbar außer Kontrolle gerät.

Wo in dieser Kette der eigentliche Wert liegt, zeigt sich am ehesten, wenn Sie fragen, was ein Angreifer mit dem geringsten Risiko am meisten gewinnt:

Auffällig an dieser Tabelle ist, dass ausgerechnet die Ziele mit dem größten Schaden am wenigsten wie ein Sicherheitsvorfall aussehen. Ein manipulierter Digital Twin verursacht keinen Stillstand, ein umsortierter Transportauftrag sieht aus wie ein Softwarefehler, und eine überzogene Berechtigung wirkt auf den ersten Blick wie normale Arbeitsteilung. Genau das macht die Steuerkette zum eigentlichen Schauplatz, nicht die einzelne Zelle.

Warum Safety keine eigene Vertrauenskette teilen darf

Innerhalb dieser Vertrauenskette gibt es eine Funktion, die eine Sonderstellung verdient: die Sicherheitsfunktion selbst, also alles, was eine Zelle bei einer gefährlichen Abweichung in einen sicheren Zustand bringt. MITRE nennt für Loss of Safety (T0880) zwei Gegenmaßnahmen: Safety-Systeme vom Betriebsnetz trennen und mechanische Schutzebenen mit möglichst wenig digitaler Angriffsfläche einsetzen. Wenn Prozesssteuerung und Sicherheitsfunktion über dieselbe Identität, dasselbe Netzwerksegment oder denselben Fernwartungszugang laufen, fällt mit einem kompromittierten Zugang beides gleichzeitig aus – ausgerechnet in dem Moment, in dem die Sicherheitsfunktion gebraucht würde.

Für Steuerungssysteme, deren Verhalten sich selbst weiterentwickelt oder anpasst, kommt ab dem 20. Januar 2027 eine weitere Anforderung hinzu, auch wenn sie heute noch nicht anwendbar ist. Anhang III der Maschinenverordnung verlangt für selbstentwickelnde Steuerungssysteme ausdrücklich, dass sie nicht über die festgelegte Aufgabe und den festgelegten Bewegungsbereich hinaus handeln — das ist Rechtsrahmen, keine vollständige Cyber-Physical-Architektur. Wer heute Zellen mit lernender oder sich anpassender Steuerungslogik beschafft, kauft damit faktisch schon für diese Anforderung ein, obwohl die Frist noch nicht läuft.

Praktisch heißt das für die eigene Anlage: Entscheidend ist, ob die Sicherheitsfunktion einer Zelle jemals über dasselbe Konto, dieselbe Cloud-Anbindung oder denselben Netzwerkpfad erreichbar ist wie die normale Prozesssteuerung. Ist das der Fall, ist das keine Frage der Wahrscheinlichkeit, sondern der Architektur, und sie lässt sich nur durch Trennung lösen, nicht durch ein weiteres Überwachungswerkzeug obendrauf.

Machine Authority Management: Wie viel Wirkung darf eine Identität auslösen?

Ein Wartungskonto, ein Optimierungsagent, ein Flottenmanager-Dienst – jedes davon handelt in Ihrer Anlage unter einer digitalen Identität, und jede dieser Identitäten hat Rechte, die irgendjemand ihr einmal zugewiesen hat. Die Frage, die in den seltensten Pflichtenheften steht, lautet: Wie viel reale Wirkung darf diese Identität tatsächlich auslösen, verglichen mit der Aufgabe, für die sie eigentlich gedacht war?

Aus dem Prinzip der geringsten Rechte folgt: ein Agent sollte nicht mehr Berechtigung erhalten als sein Auftraggeber oder die Aufgabe erfordert — Delegationsketten sollten nachvollziehbar bleiben. Dieser Beitrag führt dafür die Arbeitsbegriffe „Machine Authority Management“, „Authority Graph“ und „Operational Intent Monitoring“ ein, ohne sie als Norm oder Industriestandard auszugeben – es handelt sich um redaktionelle Bezeichnungen für ein Prinzip, nicht um Vokabular aus einer NIST- oder MITRE-Veröffentlichung.

Ein Authority Graph wäre in diesem Sinn eine Darstellung, wer welche Rechte von wem erhalten hat und wozu: das Wartungskonto vom Servicepartner, der Optimierungsagent vom Produktionsleitsystem, die Freigabe für zwanzig Zellen gleichzeitig von einem einzelnen Administrator. Ohne eine solche Darstellung – gleich ob als Diagramm oder als einfache Tabelle geführt – bleibt unsichtbar, wenn eine Delegation über mehrere Stufen hinweg mehr Wirkung ansammelt, als jede einzelne Stufe für sich genommen plausibel erscheinen lässt.

Wer diese Frage bereits auf der Ebene der Handlungsbefugnis autonomer Agenten insgesamt stellt – über die einzelne Fabrik hinaus, mit Governance-Ebenen und Allianzen zwischen Organisationen – findet dazu eine breitere Einordnung in einem eigenen Beitrag zur Sicherheit von KI-Agenten im Bestand. Für die einzelne Anlage reicht zunächst die enger gefasste Frage: Welches Konto könnte, wenn es kompromittiert wäre, wie viel gleichzeitig bewegen? Ein Authority Graph beantwortet genau das, bevor der Ernstfall die Antwort liefert.

Semantische Anomalien: Wenn ein Befehl technisch gültig, aber falsch ist

Ein Befehl kann technisch korrekt signiert, verschlüsselt und authentifiziert sein und trotzdem der falsche Befehl sein. Ein Wartungskonto, das plötzlich an zwanzig Zellen gleichzeitig Parameter ändern will, wirkt aus Sicht der klassischen Zugriffskontrolle völlig legitim, obwohl sein eigentlicher Auftrag nur eine einzelne Maschine betraf. Genau diese Lücke – zwischen dem, was technisch erlaubt ist, und dem, was inhaltlich zum aktuellen Auftrag passt – beschreibt dieser Beitrag mit dem Arbeitsbegriff Operational Intent Monitoring, ebenfalls eine redaktionelle Bezeichnung und kein etablierter Fachterminus aus MITRE oder einer vergleichbaren Quelle.

Klassische Anomalieerkennung sucht nach ungewöhnlichem Netzwerkverkehr, ungewöhnlichen Uhrzeiten, ungewöhnlichen IP-Adressen. Das bleibt notwendig, erfasst aber nicht jeden Fall, denn ein Angreifer, der ein legitimes Konto übernommen hat, bewegt sich zunächst innerhalb aller technischen Regeln. Was fehlt, ist ein Abgleich zwischen der Handlung und der Aufgabe, für die die Identität eigentlich freigegeben wurde: Passt die Parameteränderung zum aktuellen Fertigungsauftrag? Passt die Zahl der betroffenen Zellen zum üblichen Muster dieses Kontos? Passt der Zeitpunkt zum vereinbarten Wartungsfenster?

Diese Fragen lassen sich nicht allein technisch beantworten, weil sie Prozesswissen voraussetzen – welche Zelle gerade was produziert, welcher Auftrag welche Priorität hat. Operational Intent Monitoring bleibt deshalb in der Praxis ein Zusammenspiel aus Produktionsleitsystem und Sicherheitsüberwachung, nicht eine zusätzliche Software, die man einfach dazukauft.

Der Digital Twin als Schutz- und Angriffsziel

Ein Digital Twin bildet einen Prozess, eine Zelle oder eine ganze Linie so detailliert nach, dass sich damit Störungen vorhersagen, Wartungsintervalle planen und neue Produkte vor der realen Fertigung simulieren lassen. Genau dieser Detailgrad macht ihn zu einem doppelten Ziel: Er schützt die Produktion, weil er Probleme sichtbar macht, bevor sie real werden – und er ist selbst schützenswert, weil in ihm oft mehr Prozesswissen steckt als in der Maschine, die er abbildet.

Ein Datenabfluss aus dem Digital Twin verursacht keinen Stillstand und löst deshalb selten einen Alarm aus, den jemand ernst nimmt. Wer Zugriff auf die Simulationsmodelle, Prozessparameter und Fehlerhistorien einer Anlage erhält, bekommt damit einen erheblichen Teil des Erfahrungswissens, das ein Unternehmen über Jahre in seine Fertigung investiert hat, ohne dass an der physischen Anlage irgendetwas anders aussehen müsste. Wo die Grenze zu einem unrechtmäßigen Abfluss solcher Daten verläuft, ordnet ein eigener Beitrag zum Datenmarkt für Roboterdaten im Bestand ein.

Die zweite Angriffsrichtung ist subtiler: eine Manipulation des Modells selbst, nicht des zugrunde liegenden Prozesses. Ein manipulierter Digital Twin könnte Wartungsintervalle falsch berechnen oder eine Störung erst dann anzeigen, wenn es zu spät ist, ohne dass die reale Anlage in diesem Moment überhaupt betroffen wäre. Das ist eine Ableitung aus der Architektur eines solchen Modells, keine aus einem konkreten, dokumentierten Vorfall belegte Aussage – aber sie folgt derselben Logik wie bei der Flottensteuerung: Zentrale Modelle konzentrieren Wirkung.

Für die eigene Bewertung lohnt sich deshalb dieselbe Frage wie bei jeder anderen Datenklasse: Wer hat Schreibzugriff auf das Modell, nicht nur Lesezugriff auf seine Ausgaben? Und wie schnell würde auffallen, wenn eine Vorhersage systematisch falsch liegt, aber plausibel genug bleibt, um nicht sofort aufzufallen? Ohne einen unabhängigen Vergleichswert – etwa reale Sensordaten neben dem Modell – bleibt diese Frage praktisch unbeantwortbar.

Vision-Systeme und die Frage nach der Sensorintegrität

Ein Roboterarm, der über eine Kamera greift, verlässt sich vollständig auf das, was ihm die Bildverarbeitung als Koordinaten liefert. Er prüft nicht nach, ob dieses Bild noch das ist, was die Kamera tatsächlich gerade sieht. Sensorintegrität bedeutet deshalb weniger, ob eine Kamera funktioniert, als ob die Kette von der Optik bis zum Koordinatenwert, den die Steuerung erhält, an jeder Stelle unverändert bleibt.

Die naheliegendste Manipulation ist rein physisch – ein verschobener Sensor, ein Aufkleber, ein verändertes Lichtverhältnis – und bleibt außerhalb dieses Beitrags, weil sie zur physischen Zugangskontrolle gehört, nicht zur digitalen Angriffsfläche. Interessanter für die Steuerkette ist die digitale Manipulation zwischen Kamera und Steuerung: ein kompromittiertes Bildverarbeitungsmodul, das plausible, aber leicht falsche Koordinaten ausgibt, oder ein Firmware-Update auf einem Sensor, das niemand mehr geprüft hat, weil es „nur ein Kamerasystem“ ist.

Der Unterschied zu einer klassischen IT-Komponente liegt in der Wirkung des Fehlers. Ein falsch ausgelesener Datensatz in einer Buchhaltungssoftware fällt spätestens beim Jahresabschluss auf. Eine leicht falsche Koordinate an einem Greifarm führt zunächst nur zu einem beschädigten Werkstück, das als Qualitätsproblem verbucht wird, nicht als Sicherheitsvorfall, obwohl beide dieselbe Ursache haben könnten. Wer Vision-Systeme in die eigene Angriffsflächenanalyse aufnimmt, sollte deshalb nicht nur fragen, ob die Kamera selbst gesichert ist, sondern ob eine Häufung von Qualitätsabweichungen an einer bestimmten Zelle jemals mit der Sicherheitsüberwachung dieser Zelle abgeglichen wird.

AMR-Flotten als konzentrierte Autorität

Eine einzelne Roboterzelle hat einen begrenzten Wirkungsradius: Sie steht an einem Ort, bewegt sich in einem definierten Bereich, und ihr Ausfall betrifft in erster Linie diese eine Station. Eine Flotte autonomer mobiler Roboter funktioniert architektonisch anders, weil eine zentrale Flottensteuerung Aufträge, Routen und Prioritäten für sämtliche Fahrzeuge gleichzeitig vergibt. Das ist der Grund, warum sich Autorität hier stärker konzentriert als bei einer einzelnen Zelle – nicht, weil ein bestimmter Vorfall das belegt, sondern weil die Architektur selbst so angelegt ist.

Ein kompromittiertes Flottenkonto könnte Transportaufträge falsch priorisieren oder Material an falsche Stationen schicken, ohne dass die Sicherheitsfunktionen der einzelnen Fahrzeuge betroffen sein müssen — eine Ableitung aus der Architektur, kein dokumentierter Vorfall. Kein Fahrzeug fährt gegen ein Hindernis, keine Sicherheitsabschaltung greift – trotzdem stimmt der Materialfluss nicht mehr.

Für die Bewertung der eigenen Flotte zählt deshalb weniger die Frage, ob die einzelnen Fahrzeuge sicher sind – das prüfen ohnehin ihre mechanischen und funktionalen Sicherheitssysteme –, sondern wie viele Fahrzeuge ein einzelnes kompromittiertes Konto gleichzeitig beeinflussen kann und wie schnell sich dieser Einfluss wieder entziehen lässt. Wie eine solche Eindämmung im Einzelnen abgestuft abläuft, behandelt der Beitrag zum digitalen Not-Aus dieses Blocks; für die Flotte selbst reicht hier die Feststellung, dass ein zentraler Flottenmanager ohne eigene Autoritätsbegrenzung zum größten Einzelrisiko der gesamten Halle werden kann.

Remote Service und Lieferkette: Der Fernzugang als Einfallstor

Kaum eine moderne Roboterzelle oder AMR-Flotte kommt heute ohne Fernwartungszugang eines Herstellers oder Servicepartners aus. Das ist wirtschaftlich sinnvoll, weil Anfahrtszeiten und Stillstandskosten sinken, wenn ein Techniker aus der Ferne parametrieren kann. Es bedeutet zugleich, dass die eigene Vertrauenskette an einem Punkt endet, den man selbst nicht vollständig kontrolliert: beim Konto eines Dritten.

§ 30 BSIG nennt Lieferkettensicherheit ausdrücklich als Teil des Risikomanagements — für Fernwartungszugänge zu Robotik- und Steuerungssystemen relevant, ohne dass dieser Beitrag den vollständigen BSIG-Pflichtenkatalog aufbaut. Wer zusätzlich unter § 31 BSIG fällt, kennt bereits die nächste Stufe: § 31 BSIG verlangt von Betreibern kritischer Anlagen Systeme zur Angriffserkennung mit kontinuierlicher automatischer Auswertung — mit einem ausdrücklichen Verhältnismäßigkeitsvorbehalt; ob das eigene Unternehmen als Betreiber kritischer Anlagen gilt, ist eine Einzelfallfrage, die von Sektor, Größe und Art der Anlage abhängt und sich hier nicht pauschal beantworten lässt. Einen vollständigen Pflichtenbestand mit Schwellenwerten führt ein eigener Beitrag zur Klinik- und Betriebs-Cybersicherheit im Bestand.

Wie ein solcher Fernzugang praktisch zum Problem werden könnte, lässt sich an einem Ablauf zeigen, der bewusst als Konstruktion und nicht als Bericht gelesen werden soll. Ein mögliches Szenario könnte so aussehen – eine analytische Konstruktion zur Veranschaulichung der Angriffskette, kein Bericht über einen konkreten, öffentlich bekannten Vorfall: Ein Servicepartner-Konto würde kompromittiert, weil dessen Zugangsdaten anderswo wiederverwendet wurden. Über dieses Konto ließen sich zunächst unauffällig Prozessdaten mehrerer Zellen abziehen, ohne dass eine einzelne Abfrage für sich genommen verdächtig wirkte. Erst in einem zweiten Schritt würde derselbe Zugang genutzt, um Parameter im Flottenmanager zu verändern – nicht dramatisch, sondern in einem Maß, das noch innerhalb der üblichen Schwankung liegen könnte, bis sich Materialflüsse in der ganzen Halle langsam verschieben.

Lehrreich an diesem Ablauf: Jeder einzelne Schritt für sich betrachtet wäre unauffällig gewesen. Erst die Kombination aus einem einzigen kompromittierten Fernzugang und einer zentralen Instanz, die viel gleichzeitig bewirken kann, hätte den Schaden ausgemacht. Genau deshalb lohnt sich die Frage, wie schnell sich ein einzelnes Servicekonto vollständig sperren lässt und was an Zugriff übrig bleibt, wenn genau das passiert.

Was das für kleine und mittlere Hersteller bedeutet

Vieles hiervon setzt organisatorische Reife voraus – eine dedizierte OT-Security-Funktion, ein koppelbares Produktionsleitsystem. Für einen mittelständischen Maschinenbauer mit einer Handvoll Zellen und einem kleinen IT-Team klingt das schnell nach einem Aufwand, der nicht zur eigenen Größe passt.

Zwei Einschränkungen relativieren das, ohne das Risiko kleinzureden. Weder § 30 noch § 31 BSIG verlangt von jedem Unternehmen dasselbe – beide Pflichten sind an Größe, Sektor und Kritikalität der Anlage gebunden. Und der Grundgedanke dieses Beitrags lässt sich auch ohne teures Zusatzwerkzeug anwenden: Wer weiß, welches Konto wie viele Zellen gleichzeitig beeinflussen kann, hat den wichtigsten Schritt bereits getan, unabhängig davon, ob dafür ein ausgefeilter Authority Graph oder eine einfache Tabelle mit denselben Feldern geführt wird.

Was tatsächlich unabhängig von der Unternehmensgröße gilt, ist die Beschaffungsfrage: Ob ein neu gekaufter Roboter oder eine neue AMR-Flotte einen widerrufbaren Fernzugang, eine eigene Identitätsverwaltung und eine lokale Kernfunktion ohne Cloud-Zwang mitbringt, entscheidet sich beim Kauf, nicht erst im Vorfall. Wie die Fabrik nach einem Vorfall wieder zu einem belastbaren Betriebszustand zurückfindet, behandelt der Recovery-Beitrag dieses Blocks vertieft; für die Beschaffung reicht hier der Grundsatz, dass ein Rückbau später fast immer teurer ist als eine Vertragsklausel vorher.

Das Prüfraster: Vier Fragen an die eigene Anlage

Die vier MITRE-Techniken aus diesem Beitrag – Loss of View, Manipulation of Control, Theft of Operational Information und Loss of Safety – lassen sich zu einem Prüfraster zusammenfassen, das Sie auf Ihre eigene Steuerkette, Ihre Flotte und Ihre Datenklassen anwenden können. Es ersetzt keine vollständige Risikoanalyse, aber es zwingt zu vier konkreten Antworten statt zu einer allgemeinen Beteuerung, die IT-Sicherheit sei im Griff.

Was diese vier Fragen verbindet, ist eine Verschiebung des Blicks: weg von der einzelnen Maschine, hin zu der Kette, die sie mit Aufträgen, Daten und Berechtigungen versorgt. Der Roboterarm selbst war selten das eigentliche Ziel – interessant war fast immer, was hinter ihm hängt: der Flottenmanager, der Digital Twin, das Konto, das mehr auslösen kann, als jemand beabsichtigt hat. Wer diese vier Fragen einmal ehrlich für die eigene Anlage beantwortet, hat die Angriffsfläche nicht beseitigt, aber zum ersten Mal tatsächlich gesehen – und das ist ein Unterschied, mit dem sich arbeiten lässt.