Aceptación de riesgo en vulnerabilidades: excepciones que resisten una auditoría

Todo programa de vulnerabilidades tiene una pila de hallazgos que nadie va a corregir este trimestre. Un servidor heredado que el fabricante ya no soporta. Una base de datos de producción que solo se puede reiniciar dos veces al año. Un equipo médico que no te dejan tocar. Esa pila es normal. Lo que no es normal es cómo se gestiona en muchas organizaciones: un estado "no se corrige" en el escáner, un ticket cerrado con "aceptado por el negocio" y nadie que recuerde el motivo dos años después.

Aceptar el riesgo es una respuesta legítima. NIST, ISO 27001 y PCI DSS lo permiten. Pero lo tratan como una decisión que alguien toma y firma, no como un estado al que un hallazgo llega por inercia. En esta guía verás cómo es una aceptación de riesgo defendible, quién debería poder firmarla y qué señales deberían reabrirla de forma automática.

Aceptar el riesgo es una opción real, no un fracaso

La NIST SP 800-40 Rev. 4, la guía de referencia de gestión de parches, describe cuatro respuestas al riesgo del software vulnerable:

• Aceptar el riesgo tal como está, apoyándote en los controles existentes o porque el impacto posible es tan bajo que no hace falta hacer nada más.
• Mitigar, eliminando la vulnerabilidad (parcheando) o añadiendo controles que dificulten la explotación.
• Transferir, compartiendo las consecuencias con un tercero, por ejemplo al pasar a un servicio SaaS.
• Evitar, eliminando la superficie de ataque, por ejemplo al dar de baja el activo.

NIST recuerda además algo incómodo: por defecto, una organización ya acepta el riesgo de todas las vulnerabilidades que todavía no conoce. La pregunta no es si aceptas riesgo. Es si lo haces a sabiendas, con evidencia, o por accidente.

¿Aceptado por quién?

ISO/IEC 27001:2022 es precisa en esto. La cláusula 6.1.2 exige definir criterios de aceptación del riesgo, el umbral que separa los riesgos que tratas de los que decides conservar. La cláusula 6.1.3 exige que los dueños del riesgo aprueben el plan de tratamiento y acepten el riesgo residual.

En la práctica, eso descarta dos costumbres muy comunes:

1. El ingeniero acepta el riesgo. Quien tendría que aplicar el parche casi nunca es quien cargaría con las consecuencias de una brecha. Puede recomendar; no debería aprobar.
2. "El negocio" acepta el riesgo. Un área no es un dueño del riesgo. Una persona con nombre y autoridad sobre el activo o el proceso, sí.

Una regla sencilla que funciona: cuanto mayor es el riesgo residual, más arriba va la firma. Un hallazgo de severidad media en un servidor de pruebas interno lo puede aceptar el dueño del sistema. Una vulnerabilidad del catálogo KEV de CISA en un sistema expuesto a internet debería requerir al CISO y, idealmente, a un ejecutivo dueño del proceso de negocio.

Qué debe tener una aceptación de riesgo defendible

Si un auditor, un regulador o tu propia revisión de un incidente pregunta "¿por qué seguía abierto esto?", el registro tiene que responder solo. Como mínimo:

• Alcance. El hallazgo exacto (CVE o regla), los activos afectados y el entorno. "Todos los servidores Windows" no es un alcance.
• Motivo. La restricción concreta: no hay corrección, el fabricante ya no soporta el producto, el parche rompe una aplicación crítica o la ventana de mantenimiento está a meses.
• Riesgo en el momento de la decisión. Severidad, si se sabe que la explotan, su probabilidad de explotación y la exposición del activo. Es lo que permite ver después qué cambió.
• Controles compensatorios, si los hay, y cómo sabes que funcionan.
• Dueño y aprobador, con nombre.
• Fecha de caducidad. Toda aceptación termina. Cuando llega la fecha, se renueva con evidencia nueva o el hallazgo vuelve a la cola de remediación.

Si leíste nuestra guía de gestión de parches, es la misma idea aplicada con más rigor: la excepción es un registro con ciclo de vida, no una casilla marcada.

Controles compensatorios: la vara está más alta de lo que crees

"Tenemos un firewall" es el control compensatorio más común y uno de los más débiles. PCI DSS tiene la definición más clara de lo que debe cumplir un control compensatorio de verdad:

• Cumplir la intención y el rigor del requisito original.
• Dar un nivel de defensa similar al del control que reemplaza.
• Ir más allá de otros requisitos que ya tienes que cumplir. Un control que estabas obligado a tener de todos modos no cuenta.
• Ser proporcional al riesgo adicional de no cumplir el requisito.

PCI DSS también pide documentar cada uno con la restricción, el objetivo, el riesgo identificado, el control, cómo se validó y cómo se mantiene. No hace falta estar en alcance de PCI para tomar prestada esa estructura. Te obliga a responder lo que importa: ¿este control detiene de verdad el camino de ataque que abre la vulnerabilidad?

Los buenos controles compensatorios son específicos de la vulnerabilidad: aislar el activo en su propio segmento de red, desactivar la función vulnerable, una regla de WAF que bloquee el patrón del exploit o quitar la exposición a internet. NIST SP 800-40 añade que estas mitigaciones de largo plazo deben revisarlas de antemano los arquitectos de seguridad y reevaluarse periódicamente para confirmar que siguen siendo eficaces.

Las señales que deberían reabrir una decisión

La fecha de caducidad atrapa el deterioro lento. No atrapa una amenaza que cambia de un día para otro. Una aceptación se tomó bajo ciertas condiciones; si cambian, la decisión deja de valer. Reábrela automáticamente cuando:

• La vulnerabilidad entra en el KEV de CISA, o una fuente creíble reporta explotación activa. Mira qué significa el catálogo KEV.
• Aparece un exploit público o una prueba de concepto, o la probabilidad de explotación sube con fuerza.
• Cambia la exposición del activo: queda accesible desde internet, empieza a procesar datos sensibles o pasa a un proceso de negocio más crítico.
• El control compensatorio deja de funcionar: se elimina una regla de firewall, se fusiona un segmento o el WAF pasa a modo monitoreo.
• Sale una corrección para algo que no la tenía.

Aquí ayudan los marcos de priorización. Un árbol de decisión como SSVC de CISA hace explícitas estas entradas, de modo que los mismos datos que justificaron "seguir" también te dicen cuándo la respuesta pasó a ser "actuar".

Métricas que mantienen la aceptación honesta

El riesgo aceptado tiende a crecer en silencio. Tres números lo mantienen visible:

• Aceptaciones abiertas y cuántas están vencidas. Una aceptación vencida es solo una vulnerabilidad sin parchear con papeles.
• Aceptaciones sobre vulnerabilidades explotadas. Este número debería ser pequeño, cada una debería estar firmada al nivel más alto y tener un control compensatorio probado.
• Aceptaciones sin dueño o sin control compensatorio. Son las que van a doler en la revisión de un incidente.

Repórtalas junto a las métricas de remediación, no escondidas en un registro aparte. Para saber qué mostrar a la dirección, mira métricas de riesgo cibernético para el consejo.

Preguntas frecuentes

¿ISO 27001 permite aceptar riesgos? Sí. ISO/IEC 27001:2022 exige definir criterios de aceptación del riesgo y que los dueños del riesgo acepten el riesgo residual. Lo que no permite es aceptar sin criterios o sin dueño.

¿Toda excepción debe tener fecha de caducidad? Sí. NIST SP 800-40 recomienda dar seguimiento a todas las excepciones a los planes de mantenimiento y revisarlas con regularidad para ver si el plan ya se puede aplicar. Una fecha de caducidad es la forma más simple de forzar esa revisión.

¿Y si un activo no se puede parchear nunca? Entonces la aceptación se renovará una y otra vez, y eso indica que el activo necesita su propio grupo de mantenimiento con su propio plan, como sugiere NIST: aislamiento, control de acceso estricto y monitoreo, revisados con un calendario, hasta que se pueda reemplazar.

Cómo ayuda priorIQ.ai

PriorIQ Core registra cada decisión de no remediar en Risk Accepted & Decisions, con dueño, justificación, controles compensatorios y fecha de caducidad, y guarda el historial completo en Risk Accepted y All Decisions. Como la misma plataforma prioriza por riesgo real (KEV, EPSS, exploits públicos y exposición del activo), un hallazgo aceptado sigue visible en contexto en lugar de desaparecer de la cola, y su Mitigation Backlog mantiene todo lo pendiente con dueño y SLA. Los hallazgos de ScannerIQ, CloudIQ y CodeIQ entran en el mismo modelo, así que tus excepciones cubren endpoints, nube y código por igual. Solicita una demo.