Respuesta corta: cada hallazgo priorizado termina en una de tres decisiones: parchear (aplicar la corrección del fabricante), mitigar (reducir la exposición con un cambio de configuración o un control alrededor del sistema) o aceptar (dejarlo abierto, con dueño, justificación y fecha de vencimiento). Parchear es la salida por defecto. Mitigar y aceptar requieren un motivo escrito y una fecha para volver a mirar el tema.
Toda salida distinta de parchear tiene fecha de vencimiento.
Las salidas posibles
La guía DHS/CISA (CRR Resource Guide — Vulnerability Management) habla de cuatro formas de resolver el hallazgo, que se traducen así:
| Salida | Qué es | Ejemplo |
|---|---|---|
| Parche del fabricante | Actualización que elimina la falla | apt upgrade, una actualización de Windows |
| Cambio de configuración | Apagar o endurecer lo que expone la falla | Deshabilitar un servicio que nadie usa |
| Workaround o control compensatorio | Una barrera que impide la explotación sin corregir la falla | Regla de firewall, segmentación, WAF |
| Aceptar el riesgo | Dejarlo abierto con aprobación formal | Sistema que no admite parche y no puede apagarse |
Las dos primeras eliminan el problema. La tercera lo contiene. La cuarta lo reconoce. La guía menciona también evitar y transferir el riesgo; en la práctica de una PyME, evitar suele significar dar de baja el sistema.
Cómo decidir
Un orden de preguntas que funciona para la mayoría de los casos:
- ¿Hay parche? Si sí, y se puede aplicar dentro del plazo, parchear. Fin de la discusión.
- ¿Se puede apagar o reconfigurar lo que expone la falla? Un servicio que nadie usa no necesita parche, necesita estar apagado.
- ¿Hay una barrera razonable mientras se consigue el parche? Mitigar, con fecha para el parche definitivo.
- ¿No hay parche, no hay barrera, y el sistema es necesario? Aceptar, con las reglas de más abajo.
El caso típico de la cuarta es un software heredado sin soporte del fabricante, del que depende una operación. Si el sistema es chico, está aislado y la salida es reemplazarlo, la aceptación funciona como puente hacia la baja.
Mitigaciones temporales típicas
| Mitigación | Cuándo sirve | Qué cuidar |
|---|---|---|
| Segmentación | El activo no necesita hablar con toda la red | Revisar que no se corten dependencias legítimas |
| Regla de firewall | La falla está en un puerto o servicio concreto | Bloquear solo lo necesario y documentar la regla |
| WAF | Falla en una aplicación web pública | Reduce el riesgo, no corrige el código |
| Deshabilitar el servicio | Nadie usa la función afectada | Confirmar con el dueño que no hay uso oculto |
Una mitigación reduce la probabilidad de explotación. No elimina la falla: si alguien logra saltarse la barrera, la vulnerabilidad sigue ahí. Por eso la guía indica que, cuando la salida es solo un workaround, hay que seguir vigilando la aparición de un parche del fabricante y repetir el paso completo cuando aparezca.
Probar, desplegar, registrar
La guía fija tres reglas que valen para cualquier tamaño de empresa:
- Probar antes de desplegar. Toda salida, parche o mitigación, se prueba primero para ver qué efecto tiene en la operación. Una regla de firewall mal puesta puede cortar más que la vulnerabilidad.
- Desplegar con gestión de cambios. Aunque sea una planilla de cambios con fecha, ventana y rollback, el cambio queda anotado y alguien lo aprobó.
- Registrar y seguir hasta el final. El hallazgo queda abierto en el registro hasta que la salida se aplicó en todos los activos afectados. La guía recomienda que cada cambio apunte al hallazgo y viceversa. Si el plazo se va a incumplir, se invoca el proceso de excepciones de la política.
El registro de hallazgos se trata en Registro de hallazgos: el repositorio central de vulnerabilidades.
Aceptar un riesgo sin perder el control
Aceptar es una decisión legítima. Se vuelve un problema cuando se hace sin firma y sin vencimiento, porque a los seis meses nadie recuerda quién lo aprobó ni por qué. Una aceptación válida tiene:
| Elemento | Qué contiene |
|---|---|
| Descripción | Hallazgo, activo y puntaje de prioridad |
| Motivo | Por qué no se puede parchear ni mitigar |
| Controles compensatorios | Lo que sí se hace para reducir el riesgo |
| Dueño del riesgo | Quien responde por el negocio, no solo por IT |
| Vencimiento | Fecha en la que se vuelve a decidir |
| Firma | Del dueño del riesgo y de quien autoriza |
Para el vencimiento, un criterio conservador es no superar el trimestre y revisar antes si pasa algo que cambia el cuadro: aparece un parche, el CVE entra en KEV o el activo cambia de exposición. Al vencer, la aceptación no se renueva sola: se vuelve a decidir con los datos de ese día.
Errores típicos
- Mitigación sin fecha. La regla temporal de firewall queda cuatro años.
- Aceptar por falta de tiempo. Eso es una demora y corresponde el proceso de excepción de plazos.
- No probar la mitigación. El bloqueo corta un servicio que sí se usaba.
- Aceptar sin firma del dueño del negocio. El riesgo termina siendo del técnico que lo dejó abierto.
- No volver a mirar. El parche aparece y nadie se entera.
Preguntas frecuentes
¿Puedo parchear en producción sin probar?
Con una ventana, una copia de seguridad y un plan de vuelta atrás, el riesgo es manejable en la mayoría de los casos. Lo que no se negocia es el rollback: antes de tocar, sabé cómo volver.
¿Cuánto dura una mitigación temporal aceptable?
Lo que tarde el parche, con una fecha escrita. Si pasa esa fecha, la mitigación se reevalúa como hallazgo vencido, con el mismo trato que cualquier otro.
¿Quién firma una aceptación de riesgo?
Quien responde por el proceso de negocio afectado, y quien tiene autoridad para asumir el riesgo en nombre de la empresa. En una PyME suele ser el dueño o el gerente general.
¿Un WAF alcanza para dejar una aplicación sin parchear?
Reduce el riesgo, pero no lo elimina. Sirve para ganar tiempo mientras se corrige el código o se actualiza el componente.
En resumen
Parchear cuando se puede, mitigar con fecha cuando no, aceptar con firma y vencimiento cuando no queda otra. La diferencia entre una decisión de riesgo y un descuido es que la primera está escrita, tiene dueño y se revisa. Después del cambio, falta comprobar que funcionó: Verificar la remediación: cerrar el ciclo con un reescaneo.
Esta semana: elegí los hallazgos P1 y P2 abiertos y asignale a cada uno una de las tres salidas, con fecha. Los patrones que aparezcan alimentan Causa raíz: por qué las mismas vulnerabilidades vuelven.
5 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.