Cómo calculamos el riesgo en $/año (ALE) — fórmula, tabla y ejemplo

Toda herramienta de ASM responde "¿cómo está mi postura?" con nota técnica, score CVSS o conteo de hallazgos. Ninguna de ellas cruza la puerta de la sala de dirección. "Tenemos 12 highs" no desbloquea presupuesto de remediación.

Lo que lo desbloquea es "esto cuesta $X por año si no lo corregimos." Ese número se llama ALE — Annual Loss Expectancy. Este post explica cómo Sentinela lo calcula, muestra la fórmula cruda, da un ejemplo paso a paso y enumera lo que tú necesitas rellenar para que salga de cero.

La fórmula en una línea

ALE total ($/año) = costo de downtime  +  riesgo de breach

Dos componentes. Independientes. Cada uno defendible por sí mismo. El total es la suma — sin peso mágico, sin multiplicador escondido.

La diferencia frente al resto del mercado vive en el componente 1: usamos datos de uptime reales de tu dominio, no benchmarks de industria. Por eso solo tiene sentido con uptime y seguridad en la misma plataforma. EcoTrust, GAT, Unxpose — hacen seguridad. No tienen tu historial de incidentes.

Componente 1 — Costo de downtime

downtime_cost = horas_de_incidente_observadas_365d × ingreso_por_hora

En prosa: sumamos la duración de cada incidente que el monitor de Uptime vinculado al objetivo registró en los últimos 12 meses, y multiplicamos por el ingreso por hora que declaraste.

Dos entradas, ambas tuyas:

Si no vinculas monitor, este componente queda en $0. No adivinamos. No usamos benchmarks tipo "el retail medio pierde $X". El número tiene que ser tuyo para ser defendible ante la dirección.

¿Cómo dimensionar revenue_per_hour si no lo tienes de memoria? Hay un post completo con calculadora en cuánto cuesta una hora de site fuera de línea. Spoiler: suele ser 3 a 5× el ingreso perdido puro cuando sumas CAC desperdiciado, SEO penalizado y soporte sobrecargado.

Componente 2 — Riesgo de breach

breach_ale = probabilidad(risk_tier) × impacto
impacto    = (lgpd_exposure + incident_recovery_cost) × reputation_factor

Este componente es el clásico ALE actuarial: probabilidad por impacto. La diferencia es de dónde viene cada término.

La tabla de probabilidades

La probabilidad anual de incidente viene del tier de riesgo del último audit del objetivo (resultado del score contextualizado: nota técnica + criticidad de negocio + threat-intel KEV/EPSS). Tabla calibrada:

¿Por qué esos números? Calibración basada en literatura pública (Verizon DBIR, informes Ponemon) ajustada al alcance de lo que observa una auditoría externa. Es opinable — y por eso la tabla es una constante explícita en el código, no una red neuronal escondida. Si tienes dato propio de tu sector, podemos discutir. Pero la regla tiene que ser la misma entre objetivos para que la comparación tenga sentido.

Las entradas de impacto

Tres campos que rellenas una vez por workspace en Configuración → Riesgo financiero:

¿Por qué tú los rellenas y no nosotros? Porque quien conoce el negocio eres tú. El componente 1 es objetivo (nuestros datos). El componente 2 es tu visión sobre tu impacto. Transparencia > falsa precisión.

Ejemplo completo

E-commerce de moda. Configuración:

• Monitor de Uptime: 6h12 de incidentes en los últimos 365 días
• Ingreso/hora declarado: R$ 12.000
• Último audit: nota C, criticidad de negocio alta → risk_tier = high
• Configuración → Riesgo financiero:
  • lgpd_exposure: R$ 50.000
  • incident_recovery_cost: R$ 80.000
  • reputation_factor: 1.5

Cálculo:

Componente 1 — downtime
  downtime_cost = 6.2h × 12.000        = R$ 74.400

Componente 2 — breach
  impacto       = (50.000 + 80.000) × 1.5 = R$ 195.000
  probabilidad  = 0.20  (high)
  breach_ale    = 0.20 × 195.000       = R$ 39.000

ALE total                              = R$ 113.400/año

Ese es el número que va a la reunión de dirección. No "12 highs abiertos" — R$ 113.400/año de exposición esperada si no se hace nada.

Qué cambia cuando corriges

Cada eje se mueve diferente:

• Corregir un hallazgo crítico → baja la penalidad de nota técnica → baja el risk_tier del componente 2 → la tabla de probabilidades se mueve 1 o 2 escalones → breach_ale cae a una fracción de lo que era.
• Vincular el monitor de uptime (si aún no lo vinculaste) → componente 1 sale de $0 y queda honesto.
• Reducir downtime real (HA, mejor deploy, CDN) → menos horas en la ventana de 365 días → componente 1 baja.
• Subir reputation_factor (cliente nuevo grande, SLA más agresivo) → componente 2 sube — ajustas el número a la realidad.

Y la nota técnica A–F sigue intacta. Por diseño. La nota técnica es la regla de comparación entre objetivos; el riesgo financiero es la regla de priorización. Ejes paralelos, deliberadamente.

Threat intel aún escala la probabilidad

Detalle que mucha gente pierde: si el último audit detectó un hallazgo con CVE listado en CISA KEV (catálogo de vulnerabilidades en explotación activa) o EPSS ≥ 0.5 (alta probabilidad de explotación en los próximos 30 días), el risk_tier sube un escalón automáticamente.

En la práctica esto significa: un objetivo medium con hallazgo KEV se vuelve high al instante — y el breach_ale salta de 8% × impacto a 20% × impacto. 2.5× el número anterior, sin ninguna acción humana.

Es la traducción en moneda de "esto no es teórico, está siendo explotado ahora mismo".

La lectura agregada del workspace

El número de cada objetivo suma en la vista de workspace. Para una agencia o equipo gestionando 30 clientes, eso se vuelve:

Exposición agregada del portafolio: R$ 2.847.000/año en 14 activos auditados.

Ese es el número que la dirección ve. Cuando entras al detalle, ves qué objetivos contribuyen más — y qué correcciones tienen el mayor retorno en moneda eliminada por esfuerzo.

Dónde vive esto en el producto

• Tarjeta en Security/Show — exposición del objetivo (componente 1 + componente 2 separados + total).
• Dashboard de workspace — agregado, con top contributors.
• Informe semanal — diff de exposición (subió/bajó desde la semana pasada).
• PDF de auditoría — el número aparece en el informe que entregas al cliente / dirección.

Cómo activarlo ahora (3 minutos)

1. Configuración → Riesgo financiero — habilita, rellena LGPD/recovery/reputation. Una vez por workspace.
2. Security → editar objetivo — rellena "Ingreso por hora" y selecciona el monitor vinculado (auto-sugerido cuando el host coincide). Por objetivo.
3. Ejecuta una auditoría (o espera la semanal). El número aparece en la tarjeta.

Si ya tienes un monitor de Uptime para el mismo dominio: lo preseleccionamos cuando edites el objetivo. Si aún no lo tienes, crea el monitor primero — sin él, el componente 1 queda en cero y el moat se vuelve la mitad de lo que podría ser.

Por qué esto solo tiene sentido aquí

Toda herramienta de ASM puede calcular el componente 2 (probabilidad × impacto). Algunas hasta intentan estimar el componente 1 adivinando "los sitios de e-commerce pierden en promedio $X/hora". Pero ninguna de ellas tiene tu historial de incidentes del último año — porque ninguna de ellas es también tu herramienta de uptime.

Nosotros sí. Por eso aparece el número. No es estimación de mercado — es tu hoja de cálculo.

Para entender por qué la nota técnica A–F no recibe contexto financiero (y por qué es una decisión de diseño, no un olvido), lee pentest vs auditoría continua. Para dimensionar revenue_per_hour si no lo tienes de memoria, ve a cuánto cuesta una hora de site fuera de línea.