Robotik Cyber Incident: Response-Pflichten für KRITIS

Ein autonomer Patrouilleroboter ist eine OT-Komponente am Perimeter und gleichzeitig eine physische Schutzmaßnahme. Beide Eigenschaften lösen Meldepflichten aus, sobald die Schutzfunktion ausfällt. Dieser Text beschreibt den operativen Ablauf für KRITIS-Betreiber im DACH-Raum, von der Erkennung bis zum Wiederanlauf.

Robotik Cyber Incident: Definition und Auslöser

Ein technischer Defekt liegt vor, wenn ein Akku ausfällt, ein Motor blockiert oder ein Sensor falsche Werte liefert, ohne dass externe Einwirkung erkennbar ist. Ein sicherheitsrelevanter Cybervorfall liegt vor, sobald Integrität, Verfügbarkeit oder Vertraulichkeit der Robotik-Plattform durch einen externen oder internen Angreifer beeinträchtigt wird. Die Abgrenzung erfolgt anhand der forensischen Indikatoren, nicht anhand der sichtbaren Symptome.

Typische Vektoren bei autonomen Patrouillerobotern sind drei. Erstens: kompromittierte Update-Pipeline, bei der signierte Firmware durch manipulierte Pakete ersetzt wird. Zweitens: Manipulation der MQTT- oder Telemetrie-Kanäle zwischen Roboter und Leitstand. Drittens: Funkstörung der LTE-Backhaul-Verbindung, etwa durch Jamming oder gezielte Überlast.

Indikatoren am QR-2 oder am QR-3 mit LiDAR und Drohnenerkennung sind unerwartete Routenabweichungen, wiederholte Authentifizierungsfehler an der Ladestation und Telemetrie-Drift gegen das erlernte Bewegungsprofil. Jeder dieser Indikatoren ist allein noch kein Vorfall. Die Kombination aus zwei Indikatoren innerhalb von 10 Minuten gilt im Quarero-Playbook als Stufe-2-Ereignis.

Der Schwellwert für die Meldepflicht ist eindeutig: Sobald die Schutzfunktion am Perimeter beeinträchtigt ist, greift die NIS-2-Meldepflicht. Beeinträchtigt bedeutet hier nicht vollständiger Ausfall, sondern auch reduzierte Erkennungsleistung oder Routenausfall in einem definierten Schutzbereich.

Verantwortlich für die Meldung bleibt der Betreiber, auch wenn der Roboter im Robotics-as-a-Service-Modell betrieben wird. Der Anbieter liefert technische Aufklärung. Die Meldung an die Behörde verantwortet der CISO der betreibenden Einrichtung.

Rechtlicher Rahmen: NIS-2, KRITIS-Dachgesetz, BSIG

Die NIS-2-Richtlinie verpflichtet betroffene Einrichtungen zur Frühwarnung binnen 24 Stunden, zum Zwischenbericht binnen 72 Stunden und zum Abschlussbericht binnen einem Monat. Die 24-Stunden-Frist verlangt eine Frühwarnung mit den belegbaren Eckdaten, keinen vollständigen Vorfallsbericht. Diese Unterscheidung ist im operativen Ablauf entscheidend, weil sie die Anforderungen an die Erstmeldung deutlich reduziert.

Das KRITIS-Dachgesetz erweitert die Pflichten auf physische Schutzmaßnahmen und definiert sektorübergreifende Mindestanforderungen. Autonome Robotik am Perimeter fällt damit unter beide Regime: NIS-2 für die OT-Komponente, Dachgesetz für die physische Schutzfunktion.

Die KritisV legt fest, welche Anlagen als Kritische Infrastruktur gelten und damit den Meldepflichten unterliegen. BSIG §8b verlangt die Meldung über das BSI-Meldeportal, parallel an die zuständige Sektorbehörde. Die Dokumentationspflicht umfasst die audit-fähige Vorhaltung von Logs für mindestens 24 Monate.

Die Vorstandshaftung nach NIS-2 Art. 20 ist persönlich. Eine versäumte oder verzögerte Meldung ist sanktionierbar. Details zur Auslegung dieser Haftungsnorm finden sich in der Analyse NIS-2 Vorstandshaftung. Das BBK koordiniert Bevölkerungsschutz und sektorübergreifende Resilienzanforderungen für KRITIS-Betreiber und liefert ergänzende Leitlinien für die Risikoanalyse.

Erkennung: Sensorik und Telemetrie als Frühwarnung

Der QR-2 sendet einen Heartbeat alle 5 Sekunden an das SOC. Ein Ausfall über 30 Sekunden löst einen Stufe-1-Alarm aus. Diese Schwelle ist niedrig genug, um schnelle Reaktion zu erlauben, und hoch genug, um Funkschatten und kurze Reconnects nicht als Vorfall zu werten.

Anomalie-Detektion auf Bewegungsprofilen erkennt Routenmanipulationen, ohne dass ein Operator eingreifen muss. Das System vergleicht die aktuelle Patrouille mit dem erlernten Profil der letzten 30 Tage. Abweichungen über 15 Prozent erzeugen ein Stufe-2-Ereignis.

Thermal- und LiDAR-Daten werden signiert übertragen. Ein Signaturbruch wird als Integritätsvorfall klassifiziert und führt zur sofortigen Isolierung der betroffenen Einheit. Diese Maßnahme ist automatisch, sie wartet nicht auf eine menschliche Entscheidung.

Die SIEM-Anbindung erfolgt über Syslog an Splunk, QRadar oder Sentinel. Diese drei Plattformen decken die in DACH üblichen SOC-Stacks ab. Eine Sonderintegration ist im Standardvertrag enthalten, sofern das Ziel-SIEM Syslog oder Common Event Format unterstützt.

Die Korrelation mit physischen Ereignissen wie Zaunkontakt oder Drohnensignatur reduziert Fehlalarme um etwa 60 Prozent. Dieser Wert basiert auf Auswertungen aus laufenden Deployments und ist standortabhängig. Anlagen mit hoher Wildtieraktivität liegen niedriger, urbane Standorte höher.

Eindämmung: Sofortmaßnahmen in den ersten 60 Minuten

Der erste Schritt ist die Versetzung des Roboters in den sicheren Modus. Bewegung wird gestoppt, Sensorik bleibt aktiv für Beweissicherung, Aktorik wird gesperrt. Der Roboter dokumentiert seine Umgebung weiter, ohne sich zu bewegen.

Der zweite Schritt ist die Netzwerksegmentierung. Die Roboter-Backhaul wird per VLAN vom Produktions-OT getrennt. Diese Trennung ist im Normalbetrieb bereits vorhanden, im Vorfall wird zusätzlich der Uplink des betroffenen Segments isoliert.

Der dritte Schritt ist die Rotation der Credentials. API-Token und Zertifikate der betroffenen Einheit werden revoziert, neue Token werden erst nach forensischer Freigabe ausgestellt. Dieser Punkt ist häufig der zeitkritischste, weil veraltete Token in Backups weiterleben.

Der vierte Schritt ist der Fallback auf Wachpersonal. Der vordefinierte Eskalationspfad zum Dienstleister hat ein SLA von 30 Minuten für Vor-Ort-Präsenz. Die Kosten dieses Fallbacks sind in der Kalkulation der Wachschutz-Kosten im Vergleich berücksichtigt.

Der fünfte Schritt ist die Asservierung. Ein vollständiges Image des Robotik-Controllers wird gesichert, bevor ein Neustart oder ein Software-Reset erfolgt. Ohne dieses Image ist die spätere Root-Cause-Analyse nicht audit-fähig.

Meldung: 24-Stunden-Fenster sauber bedienen

Die Erstmeldung enthält fünf Pflichtangaben: Zeitstempel der Erkennung, betroffene Anlage, vermuteter Vektor, Auswirkung auf die Schutzfunktion, ergriffene Sofortmaßnahmen. Hypothesen sind als solche zu kennzeichnen. Spekulation ist in der Erstmeldung nicht zulässig und kann die spätere Bewertung der Sorgfalt belasten.

Die Meldekanäle sind drei. Das BSI-Meldeportal ist der Primärweg. Das Sektor-CSIRT wird parallel informiert. Die zuständige Landesbehörde wird nachgelagert benachrichtigt, sofern die landesrechtliche Regelung dies vorsieht. In der Praxis bedeutet das drei separate Meldetexte mit identischem Tatsachenkern.

Ein Meldungs-Template ist als Anlage zum RaaS-Vertrag hinterlegt. Das Template ist auf das BSI-Portal-Format abgestimmt und reduziert die Bearbeitungszeit für die Erstmeldung auf typischerweise 30 bis 45 Minuten. Das Template ersetzt nicht die juristische Prüfung, es strukturiert sie.

Die Rollenklärung erfolgt vor dem Vorfall, nicht währenddessen. Der CISO meldet an die Behörde. Der Werkleiter eskaliert intern. Der Vorstand wird binnen 4 Stunden informiert. Diese Reihenfolge ist in der RACI-Matrix des betrieblichen ISMS dokumentiert und in der Tabletop-Übung getestet.

Kein Spekulieren in der Erstmeldung. Nur belegbare Fakten gehören in das Pflichtfeld, Hypothesen gehören in ein separat gekennzeichnetes Annahmenfeld. Diese Trennung schützt die Einrichtung bei späterer Akteneinsicht durch die Behörde.

Forensik und Wiederanlauf

Das forensische Image wird nach BSI-Leitfaden IT-Forensik erstellt. Die Chain of Custody wird lückenlos dokumentiert, vom Erstellungszeitpunkt bis zur Übergabe an den Forensik-Dienstleister. Jeder Bruch in dieser Kette macht den Beweis vor Gericht angreifbar.

Die Root-Cause-Analyse ist innerhalb von 14 Tagen abgeschlossen, gemeinsam mit Quarero-Engineering. Diese Frist ist eng, aber notwendig, weil der Abschlussbericht nach NIS-2 binnen einem Monat fällig ist. Methodische Referenz für die Risikobewertung autonomer Systeme liefert EN ISO 13482, die Sicherheitsanforderungen für persönliche Care-Roboter definiert. Der Standard ist auf Patrouillerobotik nicht unmittelbar anwendbar, dient aber als anerkannte methodische Grundlage.

Patch- und Hardening-Maßnahmen werden vor dem Wiederanlauf geprüft, nicht danach. Diese Reihenfolge ist nicht verhandelbar. Ein Wiederanlauf mit ungepatchter Schwachstelle disqualifiziert die gesamte Forensik.

Der Wiederanlauf erfolgt in drei Stufen. Testbetrieb 48 Stunden ohne Schutzwirkung, eingeschränkter Betrieb 72 Stunden mit reduzierter Patrouillenfrequenz, Vollbetrieb nach Freigabe durch CISO und Quarero-Engineering. Jede Stufe wird im Audit-Log dokumentiert.

Die Lessons Learned werden ins betriebliche ISMS eingespeist. Das Schutzkonzept wird aktualisiert, die Tabletop-Übung wird angepasst, die Indikatoren-Schwellwerte werden bei Bedarf nachjustiert. Ein Vorfall, der nicht zu einer dokumentierten Anpassung führt, ist nicht abgeschlossen.

Vertragliche Absicherung im RaaS-Modell

Das Incident-Response-SLA von Quarero sieht zwei Fristen vor. Engineering ist binnen 2 Stunden remote verfügbar, binnen 24 Stunden vor Ort in DACH. Diese Fristen gelten 24/7, nicht nur in Bürozeiten.

Die Haftungsteilung ist klar geregelt. Der Betreiber trägt die Meldepflicht gegenüber Behörden. Der Anbieter trägt die technische Aufklärung. Diese Trennung folgt der Logik des BSIG und vermeidet Zuständigkeitslücken.

Ein Penetrationstest wird jährlich durchgeführt, der Bericht geht an den Betreiber. Es entsteht kein Aufpreis im RaaS-Tarif. Der Bericht ist Bestandteil der Nachweispflicht gegenüber Auditoren und vereinfacht die Vorbereitung auf die zweijährliche KRITIS-Prüfung nach BSIG §8a.

Der Versicherungsnachweis ist Vertragsbestandteil. Die Cyber-Police deckt Drittschäden, einschließlich Schäden aus Robotik-Vorfällen. Die Deckungssumme wird in der Anlage zum Vertrag beziffert und an die Risikoklasse der Anlage angepasst.

Die Exit-Klausel greift bei wiederholtem schweren Vorfall ohne Behebung innerhalb von 30 Tagen. Der Betreiber kann den Vertrag außerordentlich kündigen, ohne Restlaufzeit zu vergüten. Diese Klausel ist im Standardvertrag enthalten und nicht verhandelbar.

Pilotpfad für KRITIS-Betreiber

Vor der Inbetriebnahme findet eine Tabletop-Übung mit Quarero und dem zuständigen CSIRT statt. Die Dauer beträgt 4 Stunden. Die Übung deckt drei Szenarien ab: Update-Kompromittierung, Telemetrie-Manipulation, LTE-Jamming.

Der Testlauf dauert 14 Tage und umfasst einen simulierten Incident mit vollständigem Meldedurchlauf bis zum BSI-Portal-Dry-Run. Dieser Dry-Run ist mit dem BSI vorab abgestimmt und erzeugt keine echte Meldung, dokumentiert aber den vollständigen Ablauf.

Die Integration erfolgt in das bestehende SOC. Es entsteht keine Parallelstruktur. Diese Vorgabe vermeidet redundante Alarme und reduziert die Belastung der SOC-Schichten. Die operativen Details sind in den KRITIS-Anforderungen im Überblick dokumentiert.

Die Lieferung der Robotik erfolgt binnen 48 Stunden nach Vertragsunterzeichnung. Dieser Wert gilt für Standardkonfigurationen in DACH. Sonderkonfigurationen verlängern die Lieferzeit auf bis zu 10 Werktage.

Das erste Quartal wird mit monatlichem Review begleitet, danach quartalsweise. Die Reviews umfassen Vorfallsstatistik, Indikatoren-Auswertung und Anpassungen am Schutzkonzept. Die Vorbereitung der Pilotphase orientiert sich an der KRITIS-Dachgesetz Checkliste 2026.

Für die Vertragsgestaltung und die Abstimmung der SLAs ist Marcus Köhnlein, Sales Lead Schweiz Ansprechpartner. Eine konkrete Anfrage mit Standortdaten und Sektorzuordnung erreicht uns über die Kontaktseite. Wir antworten binnen 24 Stunden mit einem Vorschlag für die Tabletop-Übung und den Testlauf.