Proteger lo que no se puede parchear ni apagar: el problema medular del OT

En TI, si un sistema tiene una vulnerabilidad, lo parchas. En OT eso muchas veces no es opción: el PLC lleva doce años corriendo, el proveedor ya no existe, no hay parche — y aunque lo hubiera, apagarlo para actualizarlo cuesta producción, que es exactamente lo que la planta no está dispuesta a perder. Entonces, ¿qué haces con lo que no se puede parchear ni apagar?

El problema medular del OT

La infraestructura industrial está llena de sistemas que no se pueden tocar: legacy sin soporte, equipos con garantía atada a no modificarlos, procesos que no toleran una ventana de mantenimiento. Decir "actualízalo" no resuelve nada. La seguridad OT seria no se trata de parchear todo — se trata de mantener seguro lo que no se puede cambiar.

¿Por qué no se puede simplemente parchear?

Desde TI parece necedad. Desde la planta hay razones concretas, y conviene conocerlas antes de proponer nada:

• No existe el parche. El fabricante descontinuó el modelo, cerró la línea de producto o dejó de existir. Hay controladores y estaciones de ingeniería operando con sistemas operativos que perdieron soporte hace más de una década.
• Actualizar exige detener el controlador. Cargar firmware nuevo en un PLC normalmente implica sacarlo de modo RUN. En un proceso continuo eso es un paro de línea, con su arranque, sus mermas y su riesgo.
• El sistema está validado tal como está. En procesos regulados o certificados, cualquier cambio obliga a revalidar. El costo del papeleo supera al del parche.
• La garantía o el soporte del integrador dependen de no modificarlo. Tocar la configuración anula la responsabilidad de quien lo instaló.

Ninguna de estas razones desaparece con insistir. Por eso la estrategia no puede depender del parche.

Controles compensatorios: proteger sin tocar

La respuesta son controles que blindan el activo por fuera, sin modificarlo:

• Virtual patching — el firewall/IPS bloquea el exploit de una vulnerabilidad conocida antes de que llegue al equipo. El activo sigue vulnerable, pero inalcanzable.
• Control de egress — el activo comprometido no puede hablar hacia afuera: sin canal de salida, no hay exfiltración ni C2.
• Segmentación — aislar el activo en su zona, de modo que un compromiso no se propague al resto de la planta.
• VIP / IP virtual — presentar el servicio sin exponer el equipo real.

¿Cómo se arma el blindaje en la práctica?

Los controles funcionan en capas y en un orden específico. Saltarse el primer paso convierte todos los demás en adivinanza:

1. Inventario y mapa de comunicaciones. Qué equipos hay, con qué firmware, y quién habla con quién, por qué protocolo y en qué dirección. Sin esto no sabes qué bloquear sin tumbar el proceso. Lo cubrimos a fondo en visibilidad de activos OT.
2. Segmentación en zonas y conductos. Agrupar los activos por criticidad y controlar cada punto por donde se comunican las zonas, que es el modelo de la IEC 62443.
3. Lista blanca de protocolos y puertos. Solo pasa lo que el proceso usa: Modbus/TCP en el 502, EtherNet/IP en el 44818, S7 en el 102, DNP3 en el 20000, según el caso. Todo lo demás se niega.
4. Virtual patching con firmas industriales. El IPS reconoce y bloquea los exploits conocidos contra ese modelo de controlador o esa versión de SCADA antes de que lleguen.
5. Salida negada por omisión. Un controlador no tiene motivo para navegar a internet. Si lo comprometen, sin canal de salida no hay exfiltración ni comunicación con el atacante.
6. Acceso remoto de proveedores controlado. Con autenticación multifactor, por tiempo limitado y registrado. Es la puerta trasera más común de una planta.

¿Qué no resuelve el virtual patching?

Ser claros con los límites es parte del trabajo. El virtual patching bloquea exploits de vulnerabilidades conocidas, pero muchos protocolos industriales tienen un problema más básico: no autentican a nadie. Modbus, por ejemplo, obedece a cualquiera que llegue al puerto 502. No hace falta un exploit; basta con enviar la instrucción correcta.

Por eso el control fino no se queda en el puerto, sino en la operación. Modbus distingue lecturas (códigos de función 1 a 4) de escrituras (códigos 5, 6, 15 y 16). Un firewall con inspección industrial puede permitir que el SCADA de supervisión lea registros y bobinas, y negar cualquier escritura que no venga de la estación de ingeniería autorizada. Eso protege el proceso aunque el protocolo nunca haya tenido seguridad.

¿Funciona de verdad? Lo probamos en casa

No lo decimos solo como teoría. En nuestra propia operación mantuvimos durante años un servidor de archivos con sistema operativo y aplicación fuera de soporte, publicado a internet porque el negocio lo necesitaba así. No se podía actualizar sin reconstruirlo desde cero, así que se protegió por fuera: publicado solo por el puerto indispensable, IPS en modo estricto delante y sin salida libre hacia internet.

Cuando hicimos la revisión forense, el resultado fue el que buscábamos: los intentos de explotación que llegaron rebotaron, no hubo webshell, no hubo compromiso y no hubo exfiltración. No lo parchamos; lo volvimos inalcanzable, y además pudimos comprobarlo con evidencia. Esa segunda parte importa tanto como la primera.

Por qué esto es una capacidad, no un producto

Cualquiera vende un firewall. Blindar un PLC de 2013 sin parar la línea es ingeniería: hay que saber qué comunica, qué no puede tocarse, y armar el candado alrededor. Esa es la diferencia entre poner una caja y proteger una operación. Y es lo que convierte una póliza de seguridad OT en algo que un director de planta compra sin dudar: mi proceso no se detiene, y aun así queda protegido.

El primer paso siempre es el mismo: ver qué tienes y cómo se comunica. Sin ese mapa, cualquier control compensatorio es a ciegas.