¿Cómo escribo un hallazgo de riesgo que el negocio actuará?

La mayoría de los hallazgos de seguridad mueren en una hoja de cálculo porque están escritos para otras personas de seguridad, no para la persona que aprueba el presupuesto. Si tu informe dice "CVE-2023-XXXX, CVSS 9.8, parchar inmediatamente," has descrito una vulnerabilidad, no un riesgo. El negocio no actúa sobre vulnerabilidades. Actúa sobre consecuencias que puede visualizar.

Por qué las puntuaciones de severidad por sí solas no mueven a nadie

CVSS te dice qué tan grave es un defecto en aislamiento. No dice nada sobre si ese defecto es alcanzable, si el activo detrás de él importa para los ingresos, o si los controles compensatorios ya lo mitigan. Un 9.8 en una máquina de desarrollo interna sin ruta de internet y sin datos sensibles no es la misma conversación que un 7.5 en la puerta de pago. Si clasificas los hallazgos puramente por CVSS gastarás tu credibilidad parcheando cosas que nunca nadie iba a explotar, y el hallazgo que realmente importaba se pierde en el ruido.

El riesgo que se actúa tiene tres ingredientes: una ruta plausible al impacto, un costo en dólares u operacional adjunto a ese impacto, y un dueño que realmente puede arreglarlo. Pierde cualquiera de esos y el hallazgo se queda en el backlog.

Construye el hallazgo alrededor de un escenario, no de una salida del escáner

En lugar de "inyección SQL encontrada en el endpoint /login," escribe el escenario: "Un atacante no autenticado puede extraer la tabla completa de clientes, incluyendo contraseñas hasheadas y direcciones de facturación, a través del formulario de login. Esta tabla respalda 40,000 cuentas activas y la misma base de datos contiene historial de pedidos vinculado al alcance PCI." Ahora el lector no está analizando una clase de vulnerabilidad, están visualizando una carta de notificación de incidente y una llamada de cumplimiento.

Una estructura útil para cada hallazgo:

• Qué puede suceder — la ruta de ataque en lenguaje simple, una o dos oraciones.
• Qué toca — sistema específico, datos específicos, proceso de negocio específico.
• Qué cuesta — horas de inactividad, exposición regulatoria, confianza del cliente, penalizaciones contractuales. Usa números reales donde los tengas (cláusulas de penalización SLA, costos de incidentes pasados, deducible de seguros cibernéticos).
• Qué se necesita para arreglarlo — esfuerzo, no solo "parchalo." A veces la corrección es una regla WAF hoy y un cambio de código en el próximo sprint.
• Quién es dueño de la corrección — un nombre o un equipo, no "IT."

Vincula el hallazgo a algo que el negocio ya monitorea

Cada empresa tiene métricas que el liderazgo ya observa: SLAs de disponibilidad, tasa de abandono, hallazgos de auditoría del último ciclo SOC 2, primas de seguros cibernéticos, un contrato de cliente específico con una cláusula de seguridad. Si puedes conectar tu hallazgo con uno de esas líneas existentes — "esta es la misma clase de problema que nuestro asegurador señaló en la última renovación" o "este flujo de datos está en alcance para la auditoría SOC 2 en Q3" — no les estás pidiendo que se preocupen por algo nuevo. Les estás mostrando una amenaza a algo por lo que ya son responsables.

Este es también el lugar donde hablar con el lado del negocio antes de finalizar el informe da dividendos. Una conversación de diez minutos con finanzas u operaciones sobre qué cuesta realmente una interrupción de cuatro horas en un sistema específico supera cualquier línea genérica de "daño reputacional." Obtén el número, citalo, avanza.

Clasifica por explotabilidad y radio de explosión, no solo por CVSS

Un enfoque de priorización que funciona:

1. ¿Es alcanzable por internet o requiere acceso interno primero?
2. ¿Hay un exploit público o es teórico?
3. ¿Toca datos regulados (PCI, PHI, PII) o sistemas de la corona?
4. ¿Cuál es el tiempo y costo real para remediar versus el costo de dejarlo?

Los hallazgos que califican alto en alcanzabilidad y radio de explosión pero solo medio en CVSS a menudo merecen saltar la cola sobre un error calificado como crítico enterrado tres saltos de red atrás detrás de una jump box con MFA.

Escribe la solicitud, no solo el problema

Termina cada hallazgo con una solicitud específica: una línea de presupuesto, una ventana de cambio, una excepción de política que cerrar, o una decisión nombrada necesaria por una fecha. "Recomendamos remediación" se ignora. "Necesitamos una ventana de mantenimiento de cuatro horas antes del 15 para parchar la puerta de pago, o aceptamos el riesgo residual por escrito" fuerza una decisión de una forma u otra. Darle al liderazgo una opción explícita de aceptar el riesgo, por escrito, con su nombre en ella, es a menudo lo que finalmente logra que la corrección sea aprobada en lugar de eso.

Si quieres practicar convertir la salida cruda del escáner en hallazgos como este, trabaja a través de los segmentos Blue Team y Offensive de Korra Studio juntos — emparejar el contexto de explotación con ejercicios de reportaje es donde esta habilidad realmente se agudiza.