Ciberresiliencia OT 2026: por qué tu BCP IT no aplica

TL;DR. Tu BCP de IT no recupera una planta. Lo confirma el Claroty State of CPS 2025: 49% de organizaciones globales sufrió más de 12 horas de downtime operacional por ciberataque en los últimos 12 meses, 45% con impacto financiero igual o mayor a US$500.000 y 27% sobre US$1 millón. El caso Jaguar Land Rover de septiembre 2025 llegó a 5 semanas de shutdown y pérdidas estimadas hasta £1,9B, superando el benchmark Colonial Pipeline. La diferencia no es de magnitud sino de mecánica: recuperar IT es restaurar datos; recuperar OT es reiniciar un proceso físico con safety, vendor-specific sequences y validación de I/O. Esta guía explica por qué tu BCP IT no aplica, qué cambia en RTO/RPO al cruzar de IT a OT, qué exige ISA/IEC 62443 y NIST SP 800-82 Rev. 3, y qué obligaciones agrega la Ley 21.663 ANCI a un OIV chileno.

¿Por qué un BCP IT no protege una planta industrial?

Porque el BCP IT asume que el peor evento es perder datos y horas de productividad de oficina, no detener un proceso físico que mueve material, energía o producto químico. Un plan de continuidad típico de IT prioriza restaurar Active Directory, ERP, correo y aplicaciones críticas desde respaldo, con RTO de horas y RPO de minutos. Esa lógica no traduce a una planta porque la planta no se “restaura desde backup”: se reinicia con secuencias de arranque definidas por el vendor del PLC, se sincroniza con el sistema safety, se valida la posición física de actuadores y se vuelve a hacer subir el proceso por rampa para no dañar equipos ni producto.

El Dragos 2026 OT Cybersecurity Year in Review muestra la escala del problema: 119 grupos de ransomware impactaron 3.300 organizaciones industriales en 2025, un alza del 49% frente a 2024, con manufactura concentrando más de dos tercios de las víctimas. El dwell time promedio del atacante fue de 42 días, pero baja a 5 días cuando la organización tiene visibilidad OT madura. La mayoría de las plantas chilenas medianas opera con visibilidad cero del bus industrial, lo que significa que cuando se detecta el ataque, los controladores ya están comprometidos y el recovery requiere intervención física directa por sitio.

¿Qué diferencia técnica hay entre recovery IT y recovery OT?

Hay tres diferencias estructurales que rompen el paralelismo IT-OT.

Primera: el activo es físico. Un PLC, un RTU, un controlador SCADA o un robot industrial son objetos físicos con firmware, configuración y posición lógica de I/O. Restaurar uno no es desplegar una VM; es flashear firmware, restaurar configuración vendor-specific, conectar I/O, validar señales y sincronizar con safety. Cada vendor (Siemens, Rockwell, Schneider, ABB, Yokogawa, Emerson) tiene su procedimiento. Sin runbook por marca y modelo no hay recovery posible en ventana razonable.

Segunda: hay safety functions de por medio. En procesos con SIS (Safety Instrumented Systems) bajo IEC 61511, el reinicio del control no se hace si la zona safety no está en estado seguro. Saltar la verificación safety puede gatillar un evento físico (presión, temperatura, liberación química) con consecuencia humana o ambiental. Por eso el recovery OT es más lento que el IT incluso cuando los respaldos están perfectos: hay validaciones físicas obligatorias.

Tercera: el estado físico del proceso no se rebobina. Si una línea de pintura se detiene a mitad de ciclo, el lote se pierde. Si un horno cae fuera de rampa térmica, hay que enfriarlo, inspeccionarlo y volver a calentar. Si un molino se enfrió, el arranque puede demorar horas. El RPO en OT muchas veces no se mide en bytes perdidos sino en lote físico perdido o en horas de rampa para volver al estado operativo.

¿Qué dicen ISA/IEC 62443 y NIST SP 800-82 sobre recovery OT?

Los dos marcos coinciden en una idea central: el recovery OT es un dominio aparte del recovery IT y se rige por requisitos propios que cubren respaldo, reconstitución, energía de emergencia y mínima funcionalidad. El NIST SP 800-82 Rev. 3, publicado en septiembre 2023, dedica capítulos a la planificación de recuperación de OT y explicita que el RTO se debe definir por zona OT según tolerancia operacional y safety, no por estándar IT. Como ejemplo, observa que un RTO de 24 horas puede ser aceptable para un servidor de archivos pero inaceptable para el SCADA de un ducto de transporte de hidrocarburos.

ISA/IEC 62443-3-3 formaliza esto en el Foundational Requirement 7 “Resource Availability”, con ocho System Requirements: protección frente a denegación de servicio (SR 7.1), gestión de recursos (SR 7.2), respaldo (SR 7.3), recovery and reconstitution (SR 7.4), energía de emergencia (SR 7.5), configuración segura de red (SR 7.6), mínima funcionalidad (SR 7.7) e inventario de componentes (SR 7.8). La parte 62443-2-1 obliga al programa de seguridad a documentar y mantener estas capacidades, y la parte 62443-4-2 las traslada al vendor: tu PLC nuevo debe tener capacidad de recovery validable, no es opcional.

La consecuencia práctica para un equipo TI chileno: si tu BCP solo cita ISO 22301 o ISO 27031, no estás cubierto del lado OT. Hay que mapear cada zona industrial (Purdue Level 0 a 3) a los SR 7.x correspondientes y demostrar evidencia de cada uno.

¿Cómo se construyen RTO y RPO realistas para una zona OT?

Partiendo del proceso físico, no del catálogo de aplicaciones. El método que funciona en plantas chilenas tiene cuatro pasos.

Paso 1: BIA por zona OT, no por aplicación. Se mapea la planta en zonas Purdue (Level 0 sensores y actuadores, Level 1 controladores PLC/RTU, Level 2 SCADA/HMI, Level 3 MES/historian) y se evalúa para cada zona qué pasa físicamente si cae 1 hora, 4 horas, 24 horas. El resultado son tolerancias operacionales y de safety por zona, no por servidor.

Paso 2: RTO derivado de safety primero, economía después. Si la pérdida de control activa SIS, el RTO efectivo es 0 (el sistema safety debe seguir operativo aún sin control). Si la pérdida de control solo detiene producción, el RTO se calcula sobre costo por hora de la línea. El downtime promedio industrial cuesta US$125.000 por hora según ABB; en minería pesada llega a US$380.000 por hora. Eso fija el techo de inversión en recovery.

Paso 3: RPO definido por estado físico, no por bytes. Para un horno la pregunta no es cuántos datos perdiste sino en qué punto de la rampa estabas. Para un reactor químico la pregunta es si la reacción quedó en estado seguro o si requiere intervención. Define puntos lógicos de “estado conocido” del proceso y respalda la receta, parámetros y secuencia de arranque hasta ese punto.

Paso 4: validación física obligatoria post-recovery. Antes de declarar la zona “restaurada” hay que pasar checklist de I/O, verificar lecturas contra patrón conocido y obtener autorización de operaciones. Sin este paso el recovery TI puede “estar arriba” mientras la planta está fuera de control.

¿Qué debe incluir un runbook de recovery OT específico?

Un runbook OT vivo, no un PDF guardado en el ERP, con al menos estos siete bloques.

1. Inventario por sitio y por zona. PLCs, RTUs, HMIs, switches industriales, gateways OPC, servidores SCADA, historians, con marca, modelo, firmware, ubicación física y dependencias. El Claroty State of CPS OT Exposures 2025 registra 111.000 dispositivos OT con vulnerabilidades conocidas activas, 68% vinculadas a ransomware; sin inventario no hay defensa ni recovery.
2. Procedimientos de respaldo por vendor. Schneider, Siemens, Rockwell, Yokogawa, Emerson y ABB tienen procesos distintos. El runbook debe documentar el proceso para cada uno presente en el sitio, incluyendo frecuencia, destino y validación.
3. Secuencias de arranque por proceso. Orden estricto: energía a tablero, partida UPS, arranque servidores SCADA, validación red OT, restauración PLCs, restauración HMI, sincronización safety, validación I/O, arranque proceso por rampa.
4. Roles físicos y de control. Quién corta energía, quién opera el HMI, quién valida safety, quién autoriza arranque. Idealmente con backup definido y rotación documentada.
5. Comunicación con OT, IT y vendor. Canal cerrado para evitar usar correo o Teams comprometidos. Lista de contactos vendor 24/7 actualizada.
6. Criterios de éxito para declarar zona restaurada. Lecturas dentro de tolerancia, validación safety completa, autorización formal de operaciones.
7. Bitácora de evento. Tiempos, acciones, hallazgos. Insumo obligatorio para la notificación CSIRT bajo Ley 21.663 si el evento fue ciber.

¿Qué obligaciones impone la Ley 21.663 ANCI a un OIV chileno?

La Ley 21.663 Marco de Ciberseguridad entró en plena vigencia el 1 de enero de 2025 y el régimen sancionatorio de ANCI quedó activo desde marzo 2025. Para los Operadores de Importancia Vital (OIV) que ANCI ya calificó en su primera nómina oficial publicada en 2025, la obligación de mantener un plan de continuidad operacional adecuado al riesgo incluye explícitamente sus sistemas OT.

Eso significa cuatro cosas concretas para una planta minera, eléctrica o de saneamiento bajo OIV. Primero, el plan de continuidad debe estar documentado por zona OT con RTO y RPO específicos, no como extensión del plan IT. Segundo, debe estar testeado con evidencia (simulacro, walkthrough o tabletop). Tercero, los incidentes ciber con impacto OT entran al régimen de notificación obligatoria al CSIRT Nacional: alerta temprana en 3 horas, reporte intermedio en 72 horas, reporte final post-contención. Cuarto, la fiscalización ANCI ya está pidiendo evidencia de runbook OT y prueba reciente, con multas que pueden llegar a 40.000 UTM por incumplimiento. Para sectores cubiertos esto no es opcional ni gradual: si tu plan de continuidad no contempla OT diferenciado del IT, estás en exposición regulatoria directa.

¿Cómo se valida un plan de ciberresiliencia OT?

Con tres tipos de ejercicio escalables, cada uno con propósito distinto.

Tabletop OT trimestral. Reunión de 2-3 horas con TI, OT, operaciones, safety y management. Escenario realista: “ransomware en SCADA principal, hora pico de producción, vendor disponible solo en horario hábil EE.UU.” El equipo recorre el runbook, identifica gaps y los registra. Sin tabletop el runbook se oxida.

Walkthrough técnico semestral. Recorrido físico del runbook con los equipos OT en sitio. Se simula la secuencia de respaldo, se valida que los procedimientos vendor funcionan, se prueba el corte de comunicación IT-OT. No se detiene la planta; se valida la capacidad técnica.

Simulacro pleno anual. En ventana planificada con autorización formal, se ejecuta el recovery completo en una zona acotada. Idealmente sobre un sitio piloto o una línea no crítica. Genera la evidencia más fuerte ante ANCI y entrena al equipo en condiciones reales. El SANS State of ICS/OT 2025 reporta que los equipos que practican IR realista resultan 1,7 veces más preparados frente a un evento real.

Errores frecuentes y plan de acción 30/60/90 días

Los errores que más se repiten en plantas chilenas son cinco: pensar que el respaldo del SCADA equivale a recovery, no inventariar PLCs por vendor, no segregar la red OT, dejar safety fuera del plan y nunca probar el plan. Cualquiera de los cinco invalida el BCP.

Días 1-30 (diagnóstico). Mapear zonas Purdue por sitio, listar PLCs por vendor y modelo, identificar safety functions presentes, levantar inventario de respaldos existentes y verificar que se restauran. Output: documento de assessment OT.

Días 31-60 (diseño). Construir runbook OT por sitio con los siete bloques de la sección anterior. Definir RTO/RPO por zona usando BIA OT. Documentar contactos vendor 24/7. Establecer canal de comunicación cerrado para incidente OT. Output: runbook OT v1 firmado por OT, IT, safety y operaciones.

Días 61-90 (validación). Ejecutar tabletop OT con todos los stakeholders, corregir gaps, programar walkthrough técnico y simulacro pleno. Generar evidencia documentada para auditoría ANCI. Output: bitácora de validación y plan de mantención del runbook (revisión trimestral mínimo).

Recuperar IT es rápido y conocido. Recuperar OT es lento, físico y requiere especialización. Tu BCP solo está completo cuando ambas capas tienen runbook propio, RTO y RPO realistas y prueba reciente.

Conclusión: la planta exige su propio plan, no una extensión del de IT

El BCP IT chileno típico funciona razonablemente bien cuando el incidente está confinado a oficinas, aplicaciones y datos. Falla con consecuencias graves cuando el ataque cruza a OT y la planta queda detenida. El Claroty 2025 cuantifica el costo, Dragos cuantifica la frecuencia, y la Ley 21.663 cuantifica la consecuencia regulatoria si el OIV no demuestra plan OT diferenciado. La diferencia entre una planta que cae 4 horas y una que cae 5 semanas no son las herramientas: es el runbook OT vivo, testeado y respaldado por inventario por vendor. Empieza por mapear zonas y por separar el plan; el resto sale en orden.