SOC Anbindung Sicherheitsroboter: Warum die Schnittstelle über den Einsatzwert entscheidet

Ein Patrouillenroboter ohne SOC-Anbindung erzeugt Telemetrie, die niemand korreliert. Der Detektionswert sinkt damit auf das Niveau einer fest installierten Kamera, nur teurer und mit Rädern. Erst die strukturierte Übergabe der Events an ein Security Operations Center macht aus der Plattform ein Detektionsinstrument.

Cyber-Physical Defense Response (CDR) verknüpft physische Ereignisse mit IT-Logs in einem gemeinsamen Fall. Ein Perimeterbruch am Zaun, eine Thermalanomalie am Trafohaus und ein fehlgeschlagener Badge-Read an der Nordtür gehören in dasselbe Ticket. Ohne SOC bleibt jedes Ereignis ein Einzelereignis. Mit SOC entsteht ein Vorfall.

Der KRITIS-Dachgesetz-Entwurf verlangt Nachweise zur Detektion und Reaktion. Isolierte Robotikmeldungen erfüllen diese Pflicht nicht. Auditoren prüfen die vollständige Strecke: Sensor, Klassifikation, SIEM-Ticket, Eskalation, Einsatzbefehl.

QR-2 und QR-3 mit LiDAR und Drohnenerkennung liefern strukturierte Events als JSON über MQTT oder HTTPS, nicht als rohe Videostreams. Die Leitstelle bekommt Metadaten und einen signierten Link auf das Forensik-Material, nicht 1080p-Vollbild über eine schmale Anbindung.

Faustregel aus der Praxis: Jede Robotermeldung muss innerhalb von 30 Sekunden im SIEM-Ticket des SOC-Analysten erscheinen. Alles darüber ist eine Schnittstelle, die im Audit fragt.

Datenmodell: Was ein Sicherheitsroboter an das SOC liefern muss

Das Event-Schema steht und fällt mit Pflichtfeldern. Zeitstempel in UTC nach ISO 8601, Geo-Position in WGS84, Sensorquelle, Konfidenzwert von 0.0 bis 1.0, Klassifikation aus einem geschlossenen Vokabular (Person, Fahrzeug, Drohne, Tier, Unbekannt) sowie eine Referenz auf die Rohdaten.

Ein konkretes Event sieht in Produktion so aus:

{
  "event_id": "qr2-evt-2026-02-12T03:14:22Z-7f3a",
  "ts": "2026-02-12T03:14:22Z",
  "site": "umspannwerk-nord",
  "robot_id": "qr2-014",
  "geo": {"lat": 51.2812, "lon": 7.1934},
  "sensor": "thermal",
  "classification": "person",
  "confidence": 0.87,
  "evidence_url": "https://cdr.quarerorobotics.com/e/7f3a?sig=..."
}

Heartbeat alle 10 Sekunden überwacht die Verfügbarkeit. Ein Ausfall länger als 60 Sekunden löst automatisch ein SOC-Ticket aus, denn ein stummer Roboter ist ein blinder Posten.

Die Forensik-Payload ist bewusst klein. Ein Bildausschnitt in 640x480 als JPEG reicht für die Erstverifikation. Vollvideo wird erst auf Anforderung über eine signierte URL nachgeladen. Das hält die Backbone-Last kalkulierbar.

Audit-Trail: Jede Patrouillenroute und jede Sensorauslösung wird unveränderbar in einen WORM-Speicher geschrieben, Retention 90 Tage als Standard, 180 oder 365 Tage für KRITIS-Sektoren mit höherer Nachweispflicht.

DSGVO-Konformität ist kein Add-on. Personenbezogene Frames werden nach 72 Stunden automatisch verworfen, sofern in dieser Zeit kein Vorfall geöffnet wurde. Die Löschroutine läuft als Cron-Job und wird selbst geloggt.

Protokolle und Schnittstellen: MQTT, Syslog, REST

MQTT über TLS 1.3 ist der Standard für Event-Streaming. Die Topic-Struktur folgt einem flachen, vorhersagbaren Muster:

quarero/<site>/<robot-id>/event
quarero/<site>/<robot-id>/heartbeat
quarero/<site>/<robot-id>/telemetry
quarero/<site>/<robot-id>/command

Subscribe-Rechte werden pro Topic über ACLs vergeben. Der SOC-Operator sieht event und heartbeat. Der Wartungstechniker zusätzlich telemetry. Schreibrechte auf command haben nur autorisierte Schichtleiter.

Für Splunk, QRadar und Microsoft Sentinel liefern wir parallel Syslog nach RFC 5424 im Common Event Format (CEF) aus. Damit greifen vorhandene Parser ohne Eigenentwicklung. Wer bereits Sigma-Regeln pflegt, erweitert sie um robotikspezifische Felder.

Die REST-API ist bidirektional. Das SOC kann eine Patrouille pausieren, Wegpunkte hinzufügen, die Geschwindigkeit drosseln oder einen Live-Stream anfordern. Jeder Befehl trägt eine Operator-ID und wird im Audit-Log geführt.

Webhooks gehen an Ticketsysteme wie ServiceNow oder Jira mit signierten HMAC-Headern. Der Empfänger verifiziert die Signatur vor der Verarbeitung. Replay-Schutz über Nonce und Zeitstempel ist Pflicht.

Mutual TLS zwischen Roboter und SOC-Gateway sichert die Strecke. Zertifikatsrotation läuft automatisiert alle 90 Tage über einen internen ACME-Endpunkt. [Normreferenz oder BSI-Empfehlung verlinken] Manuelle Rotation skaliert nicht über 20 Roboter hinaus.

Alarmverifikation: Vom Sensorereignis zum Einsatzbefehl

Stufe 1 läuft am Edge. Der Roboter klassifiziert lokal in unter 200 Millisekunden und sendet das Event mit Konfidenzwert. Reine Wildtiermeldungen mit Konfidenz unter 0.6 werden lokal verworfen, nicht an das SOC weitergereicht. Sonst ertrinkt die Leitstelle in Hasenmeldungen.

Stufe 2 ist menschlich. Der SOC-Analyst sieht das Event im SIEM, öffnet den Live-Stream über die signierte URL und verifiziert binnen 90 Sekunden. Playbook-gestützt: Identifizieren, Klassifizieren, Eskalieren oder Schließen.

Stufe 3 ist die Eskalation. Ein bestätigter Alarm geht an den vertraglich gebundenen Interventionsdienst oder direkt an die Landespolizei, je nach Vorfall. Die False-Positive-Rate bei QR-2 liegt nach unseren Felddaten bei 4 Prozent. [Quelle: Quarero Robotics Feldbericht 2025 – Link einfügen] Über 95 Prozent der eskalierten Vorfälle sind echte Ereignisse, nicht Schatten oder Rehe. [Quelle: Quarero Robotics Feldbericht 2025 – Link einfügen]

Doppelte Verifikation ist eine starke Karte. Der Roboter fährt nach dem Erstereignis selbsttätig zu einer zweiten Beobachtungsposition für einen unabhängigen Blickwinkel. Das reduziert Fehlalarme weiter, kostet aber etwa 40 Sekunden Reaktionszeit. Bei Hochsicherheitsperimetern lohnt sich der Kompromiss, bei Logistikflächen oft nicht.

Die Eskalationsmatrix wird im Schutzkonzept dokumentiert und mit der zuständigen Landespolizei abgestimmt. Wer das vor Inbetriebnahme versäumt, bekommt im Ernstfall Diskussionen statt Streifenwagen.

Inhouse-SOC versus externer SOC-Dienstleister

Ein Inhouse-SOC ist ab circa 4 Mio. Euro Jahresbudget realistisch. [Quelle einfügen] Drei Schichten, vier Analysten je Schicht, Tools, Räume, Schulung. Wer kleiner rechnet, baut keinen 24/7-Betrieb, sondern eine 9-bis-17-Hotline.

Externer SOC-Service ist ab 8.000 Euro monatlich für KMU-KRITIS verfügbar. [Quelle einfügen] Wir integrieren uns in bestehende Verträge mit Securitas, G4S, Prosegur und regionalen Anbietern. Das Roboter-Feed läuft im selben Mandanten wie die übrigen Kundenstandorte.

Das Hybridmodell ist bei Werkleitern beliebt. Tagschicht intern, weil die eigene Schichtleitung die Anlage kennt. Nachtschicht extern, weil drei eigene Nachtanalysten teurer und schwerer besetzbar sind als ein Dienstleistervertrag.

Der BDSW dokumentiert den Fachkräftemangel im Wachgewerbe. SOC-Personal ist innerhalb dieses Mangels noch einmal die knappste Ressource. Wer 2026 ein neues SOC aus dem Boden stampft, sollte Headhunting-Budget mit einplanen.

Vertragsklauseln zur Reaktionszeit sind verhandelbar, aber Marktstandard sind 90 Sekunden bis Sichtkontakt über den Live-Stream und 5 Minuten bis zur Interventionsdisposition. Längere Zeiten gehören in den Pönalebereich.

NIS-2 und KRITIS-Dachgesetz: Compliance-Nachweise aus der Anbindung

NIS-2 Artikel 21 fordert Maßnahmen zur Behandlung von Sicherheitsvorfällen verbindlich. Detektion, Reaktion, Wiederherstellung. Die SOC-Anbindung liefert den technischen Nachweis für Detektion und Reaktion in einem Schritt.

Die Meldepflicht von 24 und 72 Stunden lässt sich manuell nicht zuverlässig erfüllen. Automatisierte SOC-Tickets mit Zeitstempel und Audit-Trail erfüllen die Pflicht; handgeschriebene E-Mails an das BSI scheitern an der Sechs-Tage-Woche der Realität.

Das KRITIS-Dachgesetz verlangt physische Schutzmaßnahmen UND deren Wirksamkeitsnachweis. Eventlogs sind dieser Nachweis. Eine KRITIS-Dachgesetz Checkliste 2026 führt durch die einzelnen Belegpflichten.

Vorstandshaftung greift bei nachweislich fehlender Reaktionskette. Eine dokumentierte SOC-Anbindung ist Entlastungsbeweis. Wer Robotik einsetzt, aber keine SOC-Anbindung hat, schafft Schein-Compliance. Im Schadensfall wird das gegen ihn ausgelegt. Details zur NIS-2 Vorstandshaftung zeigen die persönliche Dimension.

Auditoren prüfen seit 2025 verstärkt die End-to-End-Strecke vom Sensor bis zum Einsatzbefehl. Wer nur die Hardware vorzeigt, fällt durch. Wer Eventlogs, SIEM-Tickets und Eskalationsprotokolle vorlegt, besteht. Die BSI-Kritisverordnung definiert Schwellenwerte und Sektoren, nach denen die Prüftiefe bemessen wird.

Implementierungsplan: 6 Wochen von Pilot bis Produktivbetrieb

Woche 1 ist Planung. SOC-Tooling identifizieren (Splunk, QRadar, Sentinel, Elastic), Netzwerkpfade definieren, VLAN-Segmentierung festlegen. Der Roboter gehört nicht ins Office-VLAN und nicht ins OT-Netz, sondern in ein eigenes Security-VLAN mit klaren Egress-Regeln.

Woche 2 baut die Plattform. MQTT-Broker und SIEM-Connector aufsetzen, Testereignisse durchspielen. Wir liefern Beispiel-JSON, Konfigurationen für die gängigen Broker (HiveMQ, EMQX, Mosquitto) und CEF-Mappings für die drei großen SIEMs.

Woche 3 ist Hardware. Roboter physisch zustellen (48-Stunden-Lieferung im Mietmodell), Patrouillenrouten kalibrieren, LiDAR-Karte erstellen. Bei einem mittelgroßen Standort von 30.000 Quadratmetern ist die Kalibrierung in zwei Tagen abgeschlossen.

Woche 4 ist Mensch. Alarmverifikations-Playbooks mit SOC-Analysten trainieren, Eskalationsmatrix einüben. Jeder Analyst durchläuft mindestens fünf simulierte Vorfälle vor dem Go-Live.

Woche 5 ist Tabletop. Übung mit simulierten Vorfällen: Perimeterbruch nachts, Drohnenanflug bei Wind, Brand im technischen Gebäude. Beobachter sind Werksicherheit, IT-Sicherheit, externer Auditor. Protokoll geht an die Geschäftsführung.

Woche 6 ist Produktion. Go-Live, erste Wochenauswertung, Feinjustierung der Konfidenzschwellen. Erfahrungsgemäß werden in den ersten 14 Tagen die Schwellwerte zweimal nachjustiert, bevor sich ein stabiler Betrieb einstellt.

Wirtschaftliche Betrachtung: SOC-fähige Robotik versus klassischer Wachschutz

Ein 24/7-Wachposten kostet je nach Bundesland und Tarif zwischen 15.000 und 25.000 Euro monatlich. [Quelle z. B. BDSW-Tarifübersicht einfügen] Ein QR-2 plus SOC-Anteil liegt bei 4.500 bis 5.500 Euro monatlich im Mietmodell. Die Spanne ergibt sich aus Standortgröße, Anbindungsbandbreite und SOC-Service-Level.

Die Robotik ersetzt nicht den Menschen, sondern verschiebt menschliche Arbeit in die Verifikation. Der Analyst überwachte bisher 32 Kameras auf einem Bildschirm. Jetzt verifiziert er vorgefilterte Events mit klarer Handlungsaufforderung. Das ist die Arbeit, für die er ausgebildet wurde.

Skalierungseffekt: Ein SOC-Analyst betreut 8 bis 12 Roboter über mehrere Standorte gleichzeitig. Voraussetzung: False-Positive-Rate unter 5 Prozent und Eventdichte unter 20 pro Stunde. Darüber wird die Verifikation zum Engpass.

Das Robotics-as-a-Service-Modell vermeidet CapEx. Software-Updates, Integrationen, SOC-Connector-Pflege sind im Monatspreis enthalten. Bei Eigenkauf entstehen versteckte Kosten in der Schnittstellenwartung, die im Business Case meist unterschätzt werden.

Der ROI liegt bei 7 bis 11 Monaten gegenüber konventionellem Wachschutz. Die genaue Spanne hängt von Standortgröße und vorhandener SOC-Infrastruktur ab. Wer bereits ein SIEM betreibt, erreicht den ROI schneller. Der detaillierte TCO im Vergleich zum klassischen Wachschutz bildet die einzelnen Kostenpositionen ab.

Ein wirtschaftlicher Hinweis zum Schluss: Die EN ISO 13482 regelt Sicherheitsanforderungen an Serviceroboter. Anbieter ohne diese Konformität sind in KRITIS-Ausschreibungen seit 2025 in der Regel disqualifiziert. [Quellenbeleg oder Vergabedokumentation verlinken] Im Pflichtenheft sollte die Norm explizit referenziert sein.

Für eine konkrete Integrationsplanung in Ihre SIEM-Landschaft steht Marcus Köhnlein als technischer Ansprechpartner bereit: Pilotanfrage an Marcus Köhnlein. Wer zunächst die Plattformdetails und Sensorik der nächsten Generation prüfen möchte, findet die Spezifikationen unter QR-3. Ergänzend liefert die Übersichtsseite zur NIS-2 Compliance den regulatorischen Rahmen für die Anbindung.