Live · DACH ops
03:47 · QR-2 · Sektor B · 0 anomalies04:03 · QR-7 · Gate 4 · handover ack04:11 · QR-2 · Sektor B · patrol complete · 4.2 km04:14 · Filderstadt · ops ack · all green04:22 · QR-12 · Stuttgart-W · charge cycle 84%04:30 · QR-3 · Karlsruhe · perimeter sweep · pass 3/404:38 · QR-9 · Wien-N · weather check · IP65 nominal04:45 · QR-2 · Sektor B · thermal hit reviewed · benign04:52 · QR-15 · Zürich-O · escalation queue · empty05:00 · all units · shift turnover · zero incidents03:47 · QR-2 · Sektor B · 0 anomalies04:03 · QR-7 · Gate 4 · handover ack04:11 · QR-2 · Sektor B · patrol complete · 4.2 km04:14 · Filderstadt · ops ack · all green04:22 · QR-12 · Stuttgart-W · charge cycle 84%04:30 · QR-3 · Karlsruhe · perimeter sweep · pass 3/404:38 · QR-9 · Wien-N · weather check · IP65 nominal04:45 · QR-2 · Sektor B · thermal hit reviewed · benign04:52 · QR-15 · Zürich-O · escalation queue · empty05:00 · all units · shift turnover · zero incidents
← Todos los artículos
KRITIS · Ley Marco · NIS-2

Conexión SOC robots de seguridad: CDR para KRITIS

Conexión SOC robots de seguridad: MQTT, integración SIEM, verificación de alarmas y pruebas NIS-2. Referencia técnica para operadores KRITIS.

Dr. Raphael Nagel (LL.M.) & Marcus Köhnlein
Inversor y autor · Founding Partner
Seguir en LinkedIn

Conexión SOC robots de seguridad: por qué la interfaz decide el valor operativo

Un robot de patrulla sin conexión SOC genera telemetría que nadie correlaciona. El valor de detección cae al nivel de una cámara fija, solo que más cara y con ruedas. La entrega estructurada de eventos a un Security Operations Center es lo que convierte la plataforma en un instrumento de detección.

Cyber-Physical Defense Response (CDR) enlaza eventos físicos con logs de TI en un caso común. Una brecha perimetral en la valla, una anomalía térmica en el centro de transformación y una lectura fallida de tarjeta en la puerta norte pertenecen al mismo ticket. Sin SOC cada evento queda aislado. Con SOC nace un incidente.

El borrador de la KRITIS-Dachgesetz exige pruebas de detección y reacción. Las notificaciones aisladas de robótica no cumplen esa obligación. Los auditores revisan la cadena completa: sensor, clasificación, ticket SIEM, escalado, orden de intervención.

QR-2 y QR-3 con LiDAR y detección de drones entregan eventos estructurados como JSON sobre MQTT o HTTPS, no flujos de vídeo en bruto. La central recibe metadatos y un enlace firmado al material forense, no imagen completa 1080p sobre una conexión estrecha.

Regla práctica: cada notificación de robot debe aparecer en el ticket SIEM del analista SOC en menos de 30 segundos. Todo lo que supere ese umbral es una interfaz cuestionable en auditoría.

Modelo de datos: qué debe entregar un robot de seguridad al SOC

El esquema de eventos depende de campos obligatorios. Marca temporal en UTC según ISO 8601, posición geográfica en WGS84, fuente del sensor, valor de confianza entre 0,0 y 1,0, clasificación desde un vocabulario cerrado (persona, vehículo, dron, animal, desconocido) y una referencia a los datos brutos.

Un evento concreto en producción tiene este aspecto:

{
  "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=..."
}

Un heartbeat cada 10 segundos supervisa la disponibilidad. Un corte superior a 60 segundos abre automáticamente un ticket en el SOC, porque un robot mudo es un Posten ciego.

La carga forense es deliberadamente pequeña. Un recorte de imagen de 640x480 en JPEG basta para la verificación inicial. El vídeo completo se solicita a posteriori mediante una URL firmada. Eso mantiene la carga de backbone calculable.

Audit-trail: cada ruta de patrulla y cada disparo de sensor se escribe de forma inmutable en almacenamiento WORM, retención estándar de 90 días, 180 o 365 días en sectores KRITIS con mayor obligación probatoria.

La conformidad con el RGPD no es un complemento. Los frames con personas se descartan automáticamente tras 72 horas si en ese plazo no se ha abierto un incidente. La rutina de borrado corre como cron-job y se registra a su vez.

Protocolos e interfaces: MQTT, Syslog, REST

MQTT sobre TLS 1.3 es el estándar para streaming de eventos. La estructura de topics sigue un patrón plano y predecible:

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

Los permisos de subscribe se asignan por topic mediante ACLs. El operador SOC ve event y heartbeat. El técnico de mantenimiento ve también telemetry. Solo los jefes de turno autorizados tienen permiso de escritura sobre command.

Para Splunk, QRadar y Microsoft Sentinel entregamos en paralelo Syslog según RFC 5424 en Common Event Format (CEF). Así los parsers existentes funcionan sin desarrollo propio. Quien ya mantenga reglas Sigma las amplía con campos específicos de robótica.

La API REST es bidireccional. El SOC puede pausar una patrulla, añadir puntos de ruta, reducir velocidad o solicitar un live-stream. Cada comando lleva un ID de operador y queda registrado en el audit-log.

Los webhooks van a sistemas de tickets como ServiceNow o Jira con cabeceras HMAC firmadas. El receptor verifica la firma antes de procesar. La protección contra replay mediante nonce y marca temporal es obligatoria.

Mutual TLS entre robot y gateway SOC asegura el canal. La rotación de certificados se automatiza cada 90 días mediante un endpoint ACME interno. La rotación manual no escala por encima de 20 robots.

Verificación de alarmas: del evento sensorial a la orden de intervención

La fase 1 corre en el edge. El robot clasifica localmente en menos de 200 milisegundos y envía el evento con su valor de confianza. Las notificaciones puras de fauna con confianza inferior a 0,6 se descartan localmente y no llegan al SOC. De lo contrario, la central se ahoga en avisos de liebres.

La fase 2 es humana. El analista SOC ve el evento en el SIEM, abre el live-stream a través de la URL firmada y verifica en 90 segundos. Apoyado en playbook: identificar, clasificar, escalar o cerrar.

La fase 3 es el escalado. Una alarma confirmada va al servicio de intervención contractualmente vinculado o directamente a la Landespolizei según el incidente. La tasa de falsos positivos del QR-2 se sitúa en el 4 por ciento según nuestros datos de campo. Más del 95 por ciento de los incidentes escalados son eventos reales, no sombras ni corzos.

La doble verificación es una carta fuerte. Tras el primer evento, el robot se desplaza autónomamente a una segunda posición de observación para obtener un ángulo independiente. Eso reduce aún más los falsos positivos, pero cuesta unos 40 segundos de tiempo de reacción. En perímetros de alta seguridad el compromiso compensa, en superficies logísticas a menudo no.

La matriz de escalado se documenta en el plan de seguridad y se coordina con la Landespolizei competente. Quien omita este paso antes de la puesta en servicio obtendrá discusiones en lugar de coches patrulla en el caso real.

SOC interno frente a proveedor SOC externo

Un SOC interno es realista a partir de unos 4 millones de euros de presupuesto anual. Tres turnos, cuatro analistas por turno, herramientas, salas, formación. Quien calcule menos no construye operación 24/7 sino una hotline de 9 a 17.

El servicio SOC externo está disponible desde 8.000 euros mensuales para KRITIS de pyme. Nos integramos en contratos existentes con Securitas, G4S, Prosegur y proveedores regionales. El feed del robot corre en el mismo tenant que el resto de emplazamientos del cliente.

El modelo híbrido es popular entre jefes de planta. Turno diurno interno, porque el mando de turno propio conoce la instalación. Turno nocturno externo, porque tres analistas nocturnos propios resultan más caros y más difíciles de cubrir que un contrato con proveedor.

La BDSW documenta la escasez de personal cualificado en el sector de vigilancia. Dentro de esa escasez, el personal SOC es todavía el recurso más escaso. Quien levante un SOC nuevo en 2026 debe presupuestar headhunting.

Las cláusulas contractuales de tiempo de reacción son negociables, pero el estándar de mercado es 90 segundos hasta contacto visual por live-stream y 5 minutos hasta el envío de intervención. Tiempos mayores pertenecen al ámbito de penalizaciones.

NIS-2 y KRITIS-Dachgesetz: pruebas de cumplimiento desde la conexión

El artículo 21 de NIS-2 exige medidas para el tratamiento de incidentes de seguridad con carácter vinculante. Detección, reacción, recuperación. La conexión SOC entrega la prueba técnica de detección y reacción en un solo paso.

El plazo de notificación de 24 y 72 horas no puede cumplirse de forma fiable manualmente. Los tickets SOC automatizados con marca temporal y audit-trail cumplen la obligación; los correos manuscritos al BSI fracasan ante la semana real de seis días.

La KRITIS-Dachgesetz exige medidas físicas de protección Y la prueba de su eficacia. Los logs de eventos son esa prueba. Una Checklist KRITIS-Dachgesetz 2026 recorre cada obligación probatoria.

La responsabilidad de la dirección se activa cuando se demuestra ausencia de cadena de reacción. Una conexión SOC documentada es prueba exculpatoria. Quien despliega robótica sin conexión SOC genera apariencia de cumplimiento. En caso de siniestro se interpretará en su contra. Los detalles sobre la responsabilidad de la dirección bajo NIS-2 muestran la dimensión personal.

Desde 2025 los auditores revisan con más intensidad la cadena de extremo a extremo, del sensor a la orden de intervención. Quien solo enseñe hardware suspende. Quien presente logs de eventos, tickets SIEM y protocolos de escalado aprueba. La BSI-Kritisverordnung define umbrales y sectores sobre los que se mide la profundidad de la inspección.

Plan de implementación: 6 semanas de piloto a producción

La semana 1 es planificación. Identificar tooling SOC (Splunk, QRadar, Sentinel, Elastic), definir rutas de red, fijar segmentación VLAN. El robot no pertenece a la VLAN de oficina ni a la red OT, sino a una VLAN de seguridad propia con reglas de egress claras.

La semana 2 construye la plataforma. Levantar broker MQTT y connector SIEM, simular eventos de prueba. Entregamos JSON de ejemplo, configuraciones para los brokers habituales (HiveMQ, EMQX, Mosquitto) y mappings CEF para los tres SIEM grandes.

La semana 3 es hardware. Entrega física del robot (48 horas en modelo de alquiler), calibración de rutas de patrulla, creación del mapa LiDAR. En un emplazamiento mediano de 30.000 metros cuadrados la calibración termina en dos días.

La semana 4 es personas. Entrenar los playbooks de verificación de alarmas con los analistas SOC, ensayar la matriz de escalado. Cada analista pasa por al menos cinco incidentes simulados antes del go-live.

La semana 5 es tabletop. Ejercicio con incidentes simulados: brecha perimetral nocturna, aproximación de dron con viento, incendio en edificio técnico. Observadores: seguridad de planta, seguridad TI, auditor externo. El protocolo va a la dirección.

La semana 6 es producción. Go-live, primera revisión semanal, ajuste fino de umbrales de confianza. Por experiencia, los umbrales se reajustan dos veces en los primeros 14 días antes de alcanzar un régimen estable.

Análisis económico: robótica con SOC frente a vigilancia clásica

Un Posten 24/7 cuesta, según Bundesland y convenio, entre 15.000 y 25.000 euros mensuales. Un QR-2 más cuota SOC se sitúa entre 4.500 y 5.500 euros mensuales en modelo de alquiler. El rango depende del tamaño del emplazamiento, ancho de banda de conexión y nivel de servicio SOC.

La robótica no sustituye al humano: desplaza el trabajo humano hacia la verificación. El analista vigilaba antes 32 cámaras en una pantalla. Ahora verifica eventos prefiltrados con una orden de actuación clara. Ese es el trabajo para el que está formado.

Efecto de escala: un analista SOC atiende entre 8 y 12 robots distribuidos en varios emplazamientos. Condición: tasa de falsos positivos por debajo del 5 por ciento y densidad de eventos por debajo de 20 por hora. Por encima, la verificación se convierte en cuello de botella.

El modelo Robotics-as-a-Service evita CapEx. Actualizaciones de software, integraciones y mantenimiento del SOC-connector están incluidos en la cuota mensual. En compra directa surgen costes ocultos en el mantenimiento de interfaces que el business case suele subestimar.

El ROI se sitúa entre 7 y 11 meses frente a la vigilancia convencional. El rango exacto depende del tamaño del emplazamiento y de la infraestructura SOC existente. Quien ya opera un SIEM alcanza el ROI más rápido. El TCO detallado frente al Wachschutz clásico refleja cada partida de coste.

Una observación económica final: la EN ISO 13482 regula los requisitos de seguridad para robots de servicio. Los proveedores sin esa conformidad quedan en general descalificados en licitaciones KRITIS desde 2025. La norma debe referenciarse explícitamente en el pliego de condiciones.

Para una planificación de integración concreta en su panorama SIEM, Marcus Köhnlein está disponible como interlocutor técnico: Solicitud de piloto a Marcus Köhnlein. Quien quiera revisar primero los detalles de plataforma y la sensórica de próxima generación encontrará las especificaciones en QR-3. La página resumen sobre NIS-2 Compliance aporta el marco regulatorio de la conexión.

Traducciones

Call now+49 711 656 267 63Free quote · 24 hCalculate price →