Ciberseguridad robots de vigilancia: programa obligatorio para operadores KRITIS 2026

Un robot de patrulla en el perímetro de una planta no es un sensor. Es un nodo Linux móvil con conexión inalámbrica, cámaras y altavoces. Abre cuatro vectores de amenaza simultáneamente. Quien lo opera sin perfil de hardening incumple desde octubre de 2024 el artículo 21 de NIS-2, y desde 2026 la KRITIS-Dachgesetz. Este texto se dirige a CISOs que leen informes de pentest y vigilan la responsabilidad del consejo.

Ciberseguridad robots de vigilancia: por qué 2026 es el umbral

NIS-2 obliga a los operadores KRITIS desde el 18 de octubre de 2024 a evaluar el riesgo de cada sensor conectado en el perímetro (UE) 2022/2555, art. 41. Las plataformas robóticas móviles entran en ese alcance, incluso si fueron adquiridas como medida de seguridad física. La Directiva (UE) 2022/2555 no contempla excepciones para dispositivos autónomos.

Un robot de patrulla típico genera entre 40 y 80 GB de telemetría diaria [fuente requerida]: streams de vídeo, nubes de puntos LiDAR, posiciones GPS, audio. Cada uno de esos flujos puede ser exfiltrado y manipulado. Quien no cifra el stream hacia el backend entrega un plano operativo del propio recinto.

Los incidentes de 2024 y 2025 en centros logísticos europeos siguieron todos el mismo patrón: credenciales por defecto en la interfaz de mantenimiento, brokers MQTT abiertos sin TLS, kernels Linux sin parchear. Los atacantes no necesitaron zero-days. Necesitaron Shodan y 20 minutos. [fuente requerida]

El borrador de la KRITIS-Dachgesetz exige resiliencia física y digital como objeto único de evidencia. La antigua separación entre Werkschutz y seguridad TI ya no es auditable. Ambas disciplinas entregan en el mismo documento.

§38 de NIS-2 afecta personalmente al consejo de dirección. En un incidente con un robot de vigilancia sin hardening responde el consejo, no el departamento de compras. La lógica de responsabilidad la resumimos en Responsabilidad del consejo bajo NIS-2.

Superficies de ataque de robots de patrulla autónomos

Un robot de vigilancia expone al menos seis superficies de ataque. Cada una requiere un perfil de hardening propio.

Interfaces inalámbricas. Módem 4G/5G para la conexión primaria al backend, Wi-Fi como respaldo, Bluetooth para diagnóstico de mantenimiento. Cada interfaz es un vector de amenaza independiente. Un fallback Wi-Fi sin WPA3-Enterprise ya no es defendible en 2026. Bluetooth debe estar desactivado en operación regular y solo activable mediante token de mantenimiento firmado.

Capa de sensores. Cámaras térmicas, LiDAR y micrófonos son vulnerables a estímulos físicos dirigidos. El deslumbramiento láser contra LiDAR y los ultrasonidos contra micrófonos MEMS son ataques documentados. El hardening se aplica en la capa de evaluación: verificación de plausibilidad, fusión de sensores, umbrales de descarte ante anomalías de señal.

Compute onboard. Módulos NVIDIA Jetson o x86 bajo Linux. Kernels obsoletos y controladores CUDA sin parchear tienen puntuaciones CVSS superiores a 9.0 en el NVD. Quien no minimiza el userland transporta un arsenal de ataque con cada patrulla.

Conexión al backend. La integración con VMS funciona vía ONVIF, RTSP o MQTT. Los streams sin cifrar dejan de ser auditables en 2026. RTSP sin TLS y MQTT sin mTLS caen en el primer paso de auditoría.

Cadena de suministro. Las actualizaciones de firmware Over-the-Air son el vector más peligroso. Sin cadena de arranque firmada, cada update es un posible ataque a la cadena de suministro. El atacante no necesita alcanzar físicamente el robot si alcanza el servidor de actualización.

Acceso físico. Puertos USB, tapas de mantenimiento, ranuras SIM. La detección de manipulación debe cubrir tres niveles: eléctrico (interruptor), criptográfico (boot attestation) y procesal (mantenimiento bajo principio de cuatro ojos).

NIS-2 y KRITIS-Dachgesetz: obligaciones concretas para operadores de robots

El artículo 21 de NIS-2 exige cuatro disciplinas a las entidades esenciales: gestión de riesgos, incident handling, continuidad de negocio, seguridad de la cadena de suministro. Los robots de vigilancia entran en las cuatro. La clasificación como "medida física" no exime.

La obligación de notificación es concreta: los incidentes de seguridad en el robot (compromiso del control, acceso no autorizado al stream, alarma de tampering sin esclarecer) deben notificarse al BSI como alerta temprana en 24 horas. La notificación del incidente sigue a las 72 horas, el informe final al mes.

§11 del borrador de la KRITIS-Dachgesetz exige medidas de protección documentadas contra amenazas físicas y ciberfísicas en un mismo expediente. La KritisV sigue siendo aplicable en paralelo y define umbrales por sector.

La auditoría obligatoria cada tres años incluye un test de penetración del sistema robótico junto con su conexión al backend. Quien excluye el robot de la auditoría por clasificarlo como medida física se arriesga a requerimientos posteriores y plazos de mora.

En caso de incumplimiento se aplican multas de hasta 10 millones de euros o el 2 por ciento de la facturación del grupo, según sector y gravedad (UE) 2022/2555, art. 34. Una visión sectorial la ofrece Requisitos KRITIS en visión general. El BBK coordina los requisitos transversales de resiliencia.

Baseline de hardening: lo que Quarero entrega por defecto

Las medidas siguientes están activas en el estado de entrega de cada robot Quarero. No son opcionales ni desactivables en operación regular.

Secure Boot. Cadena de firmware firmada desde el bootloader hasta el userland. Ningún update sin firma criptográfica del servidor de build de Quarero. Ante un error de firma el dispositivo arranca en modo recovery y lo notifica a la central.

TLS 1.3 en cada conexión al backend. MQTT funciona exclusivamente sobre mTLS con certificado del lado cliente. Rotación cada 90 días vía la PKI interna. RTSP se sustituye por SRTP o se transporta por túnel IPsec.

Cifrado de disco. LUKS2 en todos los medios de almacenamiento con clave vinculada a TPM. En caso de robo o tampering las grabaciones no son legibles criptográficamente. Rotación de claves en cada ciclo de mantenimiento.

Segmentación de red. Los robots operan en VLAN dedicada. Sin routing hacia redes OT salvo regla de firewall explícita con Deep Packet Inspection. Principio Zero Trust: cada conexión se autentica, también dentro del perímetro.

Base Linux endurecida. Userland mínimo (sin compiladores, sin shells para cuentas de servicio), perfiles AppArmor por proceso, fail2ban en todos los puertos expuestos, parches CVE automáticos con SLA de 7 días para High y de 72 horas para Critical.

Interruptores anti-manipulación. Tapas de mantenimiento, puertos USB y ranuras SIM están vigilados con interruptores eléctricos. La activación genera alarma inmediata a la central y bloquea el dispositivo. En el siguiente arranque se dispara automáticamente una boot attestation. La especificación de hardware de la plataforma está en la ficha técnica del QR-3 con LiDAR y detección de drones.

Test de penetración y verificación continua

Hardening sin verificación es declaración. El ciclo siguiente forma parte de cada contrato RaaS de Quarero.

Pentest anual por tercero acreditado con certificación BSI. Alcance: interfaces inalámbricas, API backend, puertos físicos, cadena de actualización. El informe llega en paralelo al CISO y al equipo de ingeniería de Quarero. Hallazgos con CVSS ≥ 7.0 se cierran en 30 días.

Ejercicios de Red Team con intento de acceso físico una vez al año. Pregunta de control: ¿puede un atacante con herramienta de mantenimiento comercial comprometer el robot en 15 minutos sin disparar alarma? La respuesta consta en el informe del ejercicio.

Vulnerability scanning diario de los paquetes onboard contra NVD y trackers de la distribución. CVEs críticos (CVSS ≥ 9.0) se parchean en 72 horas. Altos (≥ 7.0) en 7 días. Inferiores en la ventana mensual de mantenimiento.

Conexión SIEM. Los logs de la robótica se envían vía syslog-ng u OTLP al SOC central, correlacionados con eventos perimetrales, sistemas de control de acceso y VMS. Las alarmas de tampering disparan automáticamente un ticket de incidente con prioridad P1.

Informe trimestral de auditoría al CISO. Contenido: estado de parches por clase CVE, número de incidentes, métricas MTTR por tipo de incidente, hallazgos abiertos de pentest y red team. El formato se acopla a la documentación NIS-2. Los detalles de la estructura de reporting están en Conformidad NIS-2 para operadores de robots.

La norma EN ISO 13482 define los requisitos de safety para robots de servicio móviles y complementa las verificaciones de security. Ambas evidencias forman parte del dossier de auditoría.

Protección de datos: tratamiento conforme al RGPD en el perímetro

NIS-2 y RGPD son regímenes distintos con ámbitos solapados. Un robot de vigilancia trata datos personales desde el momento en que una persona entra en el campo de visión.

El reconocimiento de personas anonimiza rostros por defecto mediante blurring on-device. Las imágenes en bruto solo se descifran ante alarma y con liberación bajo principio de cuatro ojos. La clave está dividida entre la dirección de la planta y el delegado de protección de datos.

Plazos de conservación: 72 horas por defecto, prorrogables hasta 30 días ante incidente documentado. Borrado automático con audit log firmado criptográficamente. La prueba de borrado forma parte del dossier RGPD.

El contrato de encargo de tratamiento se adjunta a cada contrato RaaS. Ubicación del tratamiento: centros de datos en Frankfurt y Zúrich. Sin transferencia a terceros países. Al firmar el contrato se entrega una evaluación de impacto en protección de datos, acoplable a la documentación existente del DPO del operador.

La grabación de audio se puede desactivar por ruta de patrulla. En empresas con cogestión, un acuerdo con el comité de empresa es condición previa para su activación. Quarero facilita un texto modelo, acordado en 2024 con IG Metall y ver.di.

El modelo RaaS como ventaja de ciberseguridad

La pregunta "comprar o alquilar" tiene en robótica una dimensión de seguridad que se pasa por alto en la comparativa clásica con servicios de Wachschutz.

Responsabilidad de parches en el fabricante. El operador no tiene que mantener una distribución Linux propia, compilar drivers CUDA ni firmar boot loaders. Esas tareas requieren un equipo especializado. En la mayoría de operadores KRITIS no existe ni resulta económicamente viable montarlo.

Refresh de hardware cada 24 meses. Los módulos de cómputo obsoletos salen de operación antes de convertirse en riesgo. Las placas en End-of-Life con bootroms sin parchear son un problema conocido en modelo de compra tras 36 a 48 meses. En modelo RaaS la cuestión no se plantea.

Single Point of Accountability. Un único contraparte para hardware, software, actualizaciones y respuesta a incidentes. Ante un incidente el CISO llama a un número, no a cinco. La cadena de escalado está fijada en el SLA.

OpEx mensual de 3.500 euros para el QR-2 incluye mantenimiento, parches, parte del pentest y SLA de respuesta a incidentes (precio referido a mayo de 2026, detalles en Modelo Robotics-as-a-Service). Formación, licencias de distribución e infraestructura PKI están incluidas.

Un puesto clásico de Wachschutz 24/7 cuesta entre 15.000 y 25.000 euros mensuales con menor grado de hardening cibernético [fuente requerida]. La comparativa completa de costes la ofrece Comparativa TCO frente al Wachschutz clásico. Los detalles económicos y contractuales del Modelo Robotics-as-a-Service están disponibles por separado.

Ruta de implementación: 90 días hasta operación auditable

El siguiente cronograma se ha cumplido en 11 de 13 implementaciones Quarero de 2024 y 2025 (datos internos de proyecto, disponibles bajo petición). Las dos desviaciones se debieron a liberaciones de VLAN demoradas en la red del cliente.

Semanas 1 a 2. Taller de threat modeling con CISO, dirección de planta e ingeniería de Quarero. Método: STRIDE por componente, inventario de activos, diagrama de flujos de datos. El resultado es un perfil de protección documentado con clasificación de riesgo por vector de amenaza.

Semanas 3 a 4. Segmentación VLAN, integración con backend, despliegue de certificados. Quarero proporciona plantillas PKI y playbooks de Ansible. Las reglas de firewall se aplican bajo principio de cuatro ojos con el equipo de red del operador.

Semanas 5 a 8. Operación piloto con dos rutas de patrulla. Conexión SIEM en producción, prueba de cadena de alarma con incidentes simulados, ejercicio Red Team por tercero externo. Los hallazgos se cierran antes del paso a operación regular.

Semanas 9 a 12. Informe final de pentest, finalización de la EIPD, formación del personal de la central. Entrega a operación regular con cadena de escalado documentada y hotline de soporte 24/7.

A los 90 días existe documentación auditable para la evidencia BSI, conformidad con el artículo 21 de NIS-2 y §11 de la KRITIS-Dachgesetz. La checklist operativa está en Checklist KRITIS-Dachgesetz 2026.

Quien entre en la evidencia BSI de 2026 sin este dossier recibirá requerimientos. Quien excluya en él el robot de vigilancia los recibirá dos veces. Para una primera conversación técnica con el equipo de ingeniería de Quarero concierte cita en Solicitar asesoría KRITIS.