Hay una confusión muy común cuando hablamos de seguridad en portales web: creer que mitigar una vulnerabilidad es lo mismo que corregirla. No lo es. Y entender esa diferencia puede salvarte de muchos dolores de cabeza cuando gestionas sitios institucionales donde no siempre tienes el control total del código o la infraestructura.
Lo aprendí trabajando con sistemas heredados. En varios de los portales que he administrado, especialmente en el Archivo General de la Nación, me encontré con aplicaciones legacy que llevaban años funcionando. Código antiguo, dependencias desactualizadas, frameworks que ya ni siquiera tienen soporte. Ahí es donde la diferencia entre corregir y mitigar se vuelve práctica, no teórica.
Corregir: eliminar el problema de raíz
Cuando corriges una vulnerabilidad, estás eliminando la causa del problema. Actualizas la biblioteca vulnerable, reescribes la función insegura, cambias la configuración incorrecta del servidor. Es la solución ideal. Es lo que todos queremos hacer.
Pero la realidad del sector público es otra. Un ejemplo concreto: cuando trabajaba en RAP-E Región Central, había un módulo personalizado que integraba información de varias entidades territoriales. Tenía una vulnerabilidad de inyección SQL. La corrección real implicaba reescribir buena parte del módulo, hacer pruebas exhaustivas con datos de producción de múltiples instituciones y coordinar despliegues simultáneos.
Eso toma tiempo. Y recursos. Y aprobaciones.
Mientras tanto, el sitio está expuesto. Ahí es donde entra la mitigación como estrategia temporal, pero también donde muchos cometen el error de confundirla con una solución definitiva.
Mitigar: reducir el riesgo mientras tanto
Mitigar no elimina la vulnerabilidad. La rodea. Pone capas de protección que dificultan su explotación. Es como tapar una gotera con un balde mientras consigues al plomero.
En el caso del módulo de RAP-E, mientras coordinábamos la corrección definitiva, implementamos varias medidas de mitigación: reglas específicas en el WAF para bloquear patrones de inyección SQL, restricciones adicionales de permisos en la base de datos, validación de entrada en el lado del servidor antes de que llegara al módulo vulnerable.
¿Solucionó el problema? No. ¿Redujo significativamente el riesgo de que alguien lo explotara? Sí.
La mitigación te compra tiempo. Tiempo para hacer las cosas bien, para probar adecuadamente, para conseguir presupuesto si es necesario, para coordinar con todos los actores involucrados. En portales del Estado, donde un error puede afectar servicios ciudadanos, ese tiempo es valioso.
Cuándo mitigar y cuándo corregir
La pregunta que me hago seguido es: ¿hasta dónde es aceptable quedarse solo en la mitigación? Porque he visto casos donde la "solución temporal" se vuelve permanente. La mitigación funciona, el presupuesto se va a otros proyectos, y esa vulnerabilidad queda ahí, tapada pero no resuelta.
En mi experiencia, la decisión depende de varios factores. La severidad de la vulnerabilidad, obviamente. Si es algo crítico que puede comprometer datos personales o la integridad del sistema, hay que corregir de una. Pero también importa el costo versus el riesgo residual.
He trabajado con portales informativos donde ciertas vulnerabilidades de baja criticidad se mitigaron y así quedaron porque el costo de corregirlas (reescribir sistemas completos) no se justificaba frente al riesgo real. Ojo con eso: no es negligencia si se hace conscientemente, documentando la decisión y manteniendo las mitigaciones activas.
Lo que no podés hacer es engañarte. Mitigar no es corregir. Cuando reportás el estado de seguridad de un portal, tenés que ser honesto sobre qué vulnerabilidades están realmente corregidas y cuáles solo mitigadas. Esa transparencia es bacana cuando trabajás con equipos de seguridad que hacen auditorías periódicas.
También está el tema de las actualizaciones. En CMS como WordPress o Drupal, que son muy usados en portales institucionales, actualizar el core o un plugin vulnerable es una corrección. Pero si no podés actualizar porque rompe funcionalidades personalizadas, implementar un firewall de aplicación web (WAF) con reglas específicas es una mitigación.
Lo importante es tener claro qué estás haciendo y por qué. Documentarlo. Revisarlo periódicamente. Y siempre buscar el momento adecuado para pasar de la mitigación a la corrección definitiva.
En el día a día de administrar portales del Estado, vas a enfrentarte constantemente a esta disyuntiva. Sistemas que no podés apagar, código que no podés cambiar inmediatamente, presupuestos que no alcanzan. La mitigación es una herramienta válida, no una excusa. Pero nunca debe hacerte olvidar que el objetivo final es corregir.