Robótica Cyber Incident: Obligaciones de respuesta KRITIS

Un robot de patrulla autónomo es un componente OT en el perímetro y una medida de protección física al mismo tiempo. Ambas propiedades activan obligaciones de notificación en cuanto falla la función de protección. Este texto describe el procedimiento operativo para operadores KRITIS en el espacio DACH, desde la detección hasta la reactivación.

Robótica Cyber Incident: definición y activadores

Un defecto técnico se produce cuando falla una batería, un motor se bloquea o un sensor entrega valores incorrectos sin que se detecte influencia externa. Un ciberincidente relevante para la seguridad se produce en cuanto un atacante externo o interno compromete la integridad, disponibilidad o confidencialidad de la plataforma robótica. La distinción se realiza sobre la base de los indicadores forenses, no de los síntomas visibles.

Los vectores típicos en robots de patrulla autónomos son tres. Primero: cadena de actualización comprometida, en la que el firmware firmado se reemplaza por paquetes manipulados. Segundo: manipulación de los canales MQTT o de telemetría entre el robot y el puesto de mando. Tercero: interferencia de radio en la conexión LTE de backhaul, por ejemplo mediante jamming o sobrecarga selectiva.

Los indicadores en el QR-2 o en el QR-3 con LiDAR y detección de drones son desviaciones de ruta inesperadas, errores de autenticación repetidos en la estación de carga y deriva de telemetría respecto al perfil de movimiento aprendido. Cada uno de estos indicadores por sí solo no constituye un incidente. La combinación de dos indicadores en un período de 10 minutos se clasifica como evento de nivel 2 en el playbook de Quarero.

El umbral para la obligación de notificación es inequívoco: en cuanto la función de protección en el perímetro está comprometida, entra en vigor la obligación de notificación NIS-2. Comprometida no significa aquí fallo total, sino también rendimiento de detección reducido o pérdida de ruta en una zona de protección definida.

La responsabilidad de la notificación recae en el operador, incluso cuando el robot se opera en el modelo Robotics-as-a-Service. El proveedor aporta el esclarecimiento técnico. La notificación a la autoridad es responsabilidad del CISO de la institución operadora.

Marco jurídico: NIS-2, KRITIS-Dachgesetz, BSIG

La Directiva NIS-2 obliga a las entidades afectadas a emitir una alerta temprana en 24 horas, un informe intermedio en 72 horas y un informe final en un mes. El plazo de 24 horas exige una alerta temprana con los datos esenciales verificables, no un informe de incidente completo. Esta distinción es decisiva en el procedimiento operativo porque reduce considerablemente los requisitos de la primera notificación.

El KRITIS-Dachgesetz amplía las obligaciones a las medidas de protección física y define requisitos mínimos intersectoriales. La robótica autónoma en el perímetro queda así sujeta a ambos regímenes: NIS-2 para el componente OT, Dachgesetz para la función de protección física.

La KritisV determina qué instalaciones se consideran infraestructuras críticas y están por tanto sujetas a las obligaciones de notificación. El §8b BSIG exige la notificación a través del portal de comunicación del BSI, en paralelo a la autoridad sectorial competente. La obligación de documentación comprende la conservación de registros auditables durante al menos 24 meses.

La responsabilidad personal del consejo de administración conforme al Art. 20 NIS-2 es de carácter personal. Una notificación omitida o tardía es sancionable. El análisis de la interpretación de esta norma de responsabilidad se encuentra en Responsabilidad directiva NIS-2. El BBK coordina la protección civil y los requisitos de resiliencia intersectorial para operadores KRITIS y proporciona directrices complementarias para el análisis de riesgos.

Detección: sensorización y telemetría como alerta temprana

El QR-2 envía un heartbeat cada 5 segundos al SOC. Un fallo superior a 30 segundos activa una alarma de nivel 1. Este umbral es suficientemente bajo para permitir una reacción rápida y suficientemente alto para no clasificar sombras de radio y reconexiones breves como incidente.

La detección de anomalías en perfiles de movimiento reconoce manipulaciones de ruta sin necesidad de intervención de un operador. El sistema compara la patrulla actual con el perfil aprendido de los últimos 30 días. Las desviaciones superiores al 15 por ciento generan un evento de nivel 2.

Los datos térmicos y LiDAR se transmiten firmados. Una rotura de firma se clasifica como incidente de integridad y lleva al aislamiento inmediato de la unidad afectada. Esta medida es automática y no espera a una decisión humana.

La conexión SIEM se realiza mediante Syslog a Splunk, QRadar o Sentinel. Estas tres plataformas cubren los stacks de SOC habituales en DACH. Una integración especial está incluida en el contrato estándar, siempre que el SIEM de destino soporte Syslog o Common Event Format.

La correlación con eventos físicos como contacto en la valla o firma de dron reduce las falsas alarmas en torno al 60 por ciento. Este valor se basa en evaluaciones de despliegues en curso y depende de la ubicación. Las instalaciones con alta actividad de fauna silvestre se sitúan por debajo; las ubicaciones urbanas, por encima.

Contención: medidas inmediatas en los primeros 60 minutos

El primer paso es poner el robot en modo seguro. El movimiento se detiene, la sensorización permanece activa para la preservación de evidencias y la actuación queda bloqueada. El robot sigue documentando su entorno sin moverse.

El segundo paso es la segmentación de red. El backhaul del robot se separa de la OT de producción mediante VLAN. Esta separación ya existe en funcionamiento normal; en el incidente se aísla adicionalmente el enlace ascendente del segmento afectado.

El tercer paso es la rotación de credenciales. Los tokens de API y los certificados de la unidad afectada se revocan. Los nuevos tokens solo se emiten tras la liberación forense. Este punto suele ser el más crítico en tiempo, porque los tokens obsoletos persisten en las copias de seguridad.

El cuarto paso es el repliegue al personal de seguridad. La ruta de escalada predefinida al proveedor de servicios tiene un SLA de 30 minutos para presencia in situ. Los costes de este repliegue están contemplados en el cálculo de costes de seguridad privada en comparación.

El quinto paso es el aseguramiento de evidencias. Se obtiene una imagen completa del controlador robótico antes de cualquier reinicio o restablecimiento de software. Sin esta imagen, el análisis posterior de causa raíz no es auditable.

Notificación: cumplir el plazo de 24 horas correctamente

La primera notificación contiene cinco datos obligatorios: marca de tiempo de la detección, instalación afectada, vector presunto, impacto en la función de protección y medidas inmediatas adoptadas. Las hipótesis deben identificarse como tales. La especulación no está permitida en la primera notificación y puede comprometer la valoración posterior de la diligencia aplicada.

Los canales de notificación son tres. El portal de comunicación del BSI es la vía principal. El CSIRT sectorial se informa en paralelo. La autoridad estatal competente se notifica de forma sucesiva, en la medida en que la normativa autonómica así lo prevea. En la práctica esto implica tres textos de notificación separados con un mismo núcleo factual.

Una plantilla de notificación está depositada como anexo al contrato RaaS. La plantilla está adaptada al formato del portal BSI y reduce el tiempo de elaboración de la primera notificación a típicamente 30–45 minutos. La plantilla no sustituye a la revisión jurídica; la estructura.

La asignación de roles se establece antes del incidente, no durante el mismo. El CISO notifica a la autoridad. El director de planta escala internamente. El consejo de administración se informa en un plazo de 4 horas. Este orden está documentado en la matriz RACI del ISMS operativo y probado en el ejercicio tabletop.

No se especula en la primera notificación. Solo los hechos verificables pertenecen al campo obligatorio; las hipótesis van a un campo de suposiciones identificado de forma separada. Esta separación protege a la institución ante una eventual inspección de expedientes por parte de la autoridad.

Forense y reactivación

La imagen forense se crea conforme a la Guía de Informática Forense del BSI. La cadena de custodia se documenta de forma ininterrumpida, desde el momento de creación hasta la entrega al proveedor de servicios forenses. Cualquier ruptura en esta cadena hace que la prueba sea impugnable ante un tribunal.

El análisis de causa raíz se concluye en 14 días, conjuntamente con Quarero Engineering. Este plazo es ajustado pero necesario, porque el informe final según NIS-2 vence en un mes. La referencia metodológica para la evaluación de riesgos de sistemas autónomos la aporta la EN ISO 13482, que define los requisitos de seguridad para robots de asistencia personal. La norma no es directamente aplicable a la robótica de patrulla, pero sirve como base metodológica reconocida.

Las medidas de parcheo y hardening se verifican antes de la reactivación, no después. Este orden no es negociable. Una reactivación con una vulnerabilidad sin parchear invalida la totalidad de la forense.

La reactivación se realiza en tres fases. Operación de prueba durante 48 horas sin efecto protector; operación restringida durante 72 horas con frecuencia de patrulla reducida; operación plena tras la liberación por el CISO y Quarero Engineering. Cada fase queda documentada en el registro de auditoría.

Las lecciones aprendidas se incorporan al ISMS operativo. El concepto de protección se actualiza, el ejercicio tabletop se adapta y los umbrales de indicadores se reajustan cuando es necesario. Un incidente que no conduce a una adaptación documentada no está cerrado.

Cobertura contractual en el modelo RaaS

El SLA de Incident Response de Quarero contempla dos plazos. Engineering está disponible de forma remota en 2 horas y presencialmente en DACH en 24 horas. Estos plazos rigen las 24 horas del día, los 7 días de la semana, no solo en horario de oficina.

La distribución de responsabilidad está claramente regulada. El operador asume la obligación de notificación ante las autoridades. El proveedor asume el esclarecimiento técnico. Esta separación sigue la lógica del BSIG y evita vacíos de competencia.

Una prueba de penetración se realiza anualmente; el informe se entrega al operador. No se genera ningún cargo adicional en la tarifa RaaS. El informe forma parte del deber de acreditación ante auditores y simplifica la preparación para la auditoría KRITIS bienal conforme al §8a BSIG.

El certificado de seguro es parte integrante del contrato. La póliza cibernética cubre daños a terceros, incluidos los daños derivados de incidentes robóticos. La suma asegurada se especifica en el anexo al contrato y se adapta a la clase de riesgo de la instalación.

La cláusula de salida entra en vigor ante un incidente grave repetido sin resolución en 30 días. El operador puede rescindir el contrato de forma extraordinaria sin abonar el período de vigencia restante. Esta cláusula está incluida en el contrato estándar y no es negociable.

Ruta piloto para operadores KRITIS

Antes de la puesta en servicio se realiza un ejercicio tabletop con Quarero y el CSIRT competente. La duración es de 4 horas. El ejercicio cubre tres escenarios: compromiso de actualización, manipulación de telemetría y jamming LTE.

La prueba dura 14 días e incluye un incidente simulado con el procedimiento de notificación completo hasta un dry-run del portal BSI. Este dry-run se coordina previamente con el BSI, no genera una notificación real y documenta el procedimiento completo.

La integración se realiza en el SOC existente. No se crea ninguna estructura paralela. Esta directriz evita alarmas redundantes y reduce la carga sobre los turnos del SOC. Los detalles operativos están documentados en los requisitos KRITIS: resumen.

La entrega de la robótica se produce en 48 horas tras la firma del contrato. Este valor se aplica a las configuraciones estándar en DACH. Las configuraciones especiales amplían el plazo de entrega hasta 10 días hábiles.

El primer trimestre se acompaña con revisiones mensuales; a partir de entonces, trimestrales. Las revisiones comprenden estadísticas de incidentes, evaluación de indicadores y ajustes al concepto de protección. La preparación de la fase piloto se orienta en la lista de verificación KRITIS-Dachgesetz 2026.

Para el diseño contractual y la coordinación de los SLAs, el interlocutor es Marcus Köhnlein, Sales Lead Suiza. Una consulta concreta con datos de ubicación y asignación sectorial llega a través de la página de contacto. La respuesta se produce en 24 horas con una propuesta para el ejercicio tabletop y la prueba piloto.