El sistema que no puedes apagar ni parchear: cómo se protege un legacy conectado

Hay una conversación que se repite en casi toda planta y en casi todo corporativo con algo de kilometraje. El fabricante te dice: "esta versión ya no tiene soporte, actualiza o migra". Y la operación te responde: "ese sistema corre la línea / la nómina / el control de acceso; si lo apago, paro el negocio". ¿Quién gana esa discusión? Casi siempre la operación, porque el costo de parar es inmediato y visible, y el riesgo de seguridad es difuso y futuro. Así es como un sistema heredado se queda encendido, conectado, y a veces publicado a internet, años después de que dejó de recibir parches. Es el ejemplo definitivo de una máxima de ingeniería que se repite porque es verdad: no hay nada más permanente que una solución temporal.

La pregunta interesante no es "¿por qué siguen usando eso?" —la respuesta es simple: porque funciona y no hay presupuesto ni ventana para reemplazarlo—. La pregunta interesante es: si no lo puedes apagar y no lo puedes parchear, ¿cómo lo mantienes seguro? Ahí es donde se separa quien administra infraestructura de verdad de quien solo instala cajas.

Por qué "solo actualízalo" no es una respuesta

En el mundo industrial, el legacy no es descuido: es diseño. Un PLC, un HMI o el servidor que habla con ellos se certificaron juntos, se validaron juntos, y muchas veces el proveedor del equipo prohíbe tocarlos so pena de perder la garantía o la certificación de proceso. Actualizar el sistema operativo puede romper el driver que habla con la máquina. Por eso proteger una planta no es como proteger una oficina, y por eso el modelo Purdue existe: para razonar sobre capas que no se pueden modernizar al mismo ritmo.

Y no es solo la planta. El parche que no se aplicó es hoy una de las primeras causas de brecha, pero parchar a ciegas rompe producción. Cuando el parche simplemente no existe —porque el software está fuera de vida útil— te quedas sin esa herramienta y necesitas otra cosa.

La otra cosa: controles compensatorios, en capas

La idea de fondo es vieja y sólida: si no puedes arreglar la debilidad, rodéala. No confías en que el sistema se defienda solo —no puede—, así que pones el músculo alrededor de él. En la práctica son cinco capas que trabajan juntas, ninguna suficiente por sí sola.

1. Virtual patching. Pones un IPS en línea, en modo estricto, delante del sistema sin parche. El IPS inspecciona el tráfico y bloquea el patrón del exploit antes de que llegue a la aplicación vulnerable. No parchea nada en el host —el agujero sigue ahí— pero el ataque no lo alcanza. Es comprar tiempo, y contra exploits reutilizados funciona muy bien: la mayoría del tráfico hostil de internet es escaneo automatizado disparando exploits viejos a ciegas.

2. Reducción de superficie. Publicas solo el puerto que la operación necesita, y nada más. Si el sistema sirve una aplicación web en el 443, publicas el 443 y dejas la administración (SSH, RDP, la base de datos) accesible solo desde la red interna. Cada puerto que no expones es un frente que no tienes que defender.

3. Segmentación y control de salida. Aquí está la capa que más subestima la gente. No basta con controlar quién entra al sistema; hay que controlar hacia dónde puede salir. Un servidor viejo que no necesita navegar a internet no debería poder hacerlo. ¿Por qué importa? Porque si algún día alguien logra comprometerlo, un host sin salida no puede mandar tus datos afuera ni recibir órdenes de un servidor de control. Lo dejas mudo. Es la misma jugada que vuelve inútil a un ransomware contra un repositorio de respaldo que no puede llamar a casa: cierras el canal de salida y le quitas al atacante la mitad de su juego, aunque ya esté dentro. Es la misma lógica de segmentar IT y OT sin frenar la producción: el daño se queda encerrado donde empezó.

4. Endurecimiento quirúrgico. El software viejo suele publicar de más: un directorio de datos accesible por web, un listado de archivos abierto, un log que cualquiera puede descargar. No puedes actualizar la aplicación, pero sí puedes taparle esas fugas una por una desde la configuración del servidor web, sin tocar el código. Es trabajo de bisturí, no de mazo.

5. Visibilidad y verificación. La capa que convierte todo lo anterior de "creemos que está seguro" a "lo comprobamos". Registros que se revisan, no que solo se acumulan; la capacidad de sentarte frente al sistema y responder con evidencia la única pregunta que importa el día de un susto: ¿alguien entró, o no?

Lo probamos en nuestra propia casa

Predicar esto es fácil; nosotros preferimos comérnoslo. Hace poco tomamos uno de nuestros propios sistemas heredados —una caja que operamos desde hace más de una década, con software que lleva años fuera de soporte y que ha estado publicada a internet ese tiempo— y le hicimos la autopsia completa que le haríamos a la de un cliente. No una revisión superficial: entramos con acceso total y buscamos evidencia de intrusión como si diéramos por hecho que ya había pasado.

Revisamos lo que se revisa cuando hablas en serio: cuentas de usuario y quién tiene privilegios de administrador, llaves de acceso en todo el sistema, tareas programadas que pudieran esconder un proceso malicioso, conexiones de red hacia afuera, archivos del sitio modificados en los últimos meses, y patrones de código típicos de un webshell (esa puerta trasera que un atacante deja disfrazada de archivo normal). Cruzamos todo eso contra los registros del servidor web para ver si alguna de las miles de sondas automatizadas que golpean cualquier dirección pública había logrado, aunque fuera una vez, aterrizar.

El veredicto: cero. Ninguna cuenta extraña, ninguna llave ajena, ningún proceso oculto, ningún webshell, ningún dato robado. Todo el escaneo hostil de años había rebotado. ¿La razón? El virtual patching de las capas de arriba: los exploits nunca llegaron a la aplicación sin parche porque el IPS los frenó en la puerta. La caja estaba vieja, sí, pero estaba limpia, y ahora teníamos la evidencia para afirmarlo, no la corazonada.

De paso encontramos —y cerramos en el momento— una de esas fugas del punto 4: un directorio que el software viejo servía de más. Nadie de afuera lo había tocado (los registros lo confirmaron), pero estaba abierto. Diez minutos de configuración, sin apagar el servicio, y cerrado.

La lección que te llevas

Hay dos ideas que vale la pena que te lleves de esto, tengas o no una planta.

La primera: comprar tiempo no es lo mismo que estar a salvo, pero es muchísimo mejor que estar expuesto. El virtual patching y las capas de alrededor no arreglan el sistema viejo; lo sostienen con dignidad mientras planeas su reemplazo con calma, en vez de a las carreras después de un incidente. Ese "mientras" puede durar años, y esos años son los que te permiten migrar bien.

La segunda: seguridad que no puedes verificar es fe, no seguridad. La diferencia entre "creo que estamos bien" y "revisé y estamos bien" es toda la diferencia el día que alguien —tu dirección, un cliente, una auditoría— te pregunte. Poder abrir el sistema, leer sus registros y responder con hechos es parte del servicio, no un extra.

Si tienes sistemas que no puedes apagar ni parchear —y si tu operación tiene algunos años, los tienes— la pregunta no es si algún día los reemplazarás. Es cómo los mantienes seguros hasta ese día, y cómo sabes, con evidencia y no con esperanza, que lo están. Esa es una conversación que sí vale la pena tener antes del susto, no después.