Como calculamos o risco em R$/ano (ALE) — fórmula, tabela e exemplo

Toda ferramenta de ASM responde "como está minha postura?" com nota técnica, score CVSS ou contagem de findings. Nenhum deles atravessa a porta da sala da diretoria. "Temos 12 highs" não fecha orçamento de remediação.

O que fecha é "isso custa R$ X por ano se a gente não corrigir." Esse número se chama ALE — Annual Loss Expectancy. Esse post explica como o Sentinela calcula, mostra a fórmula crua, dá um exemplo passo a passo e lista o que você precisa preencher pra ele sair de zero.

A fórmula em uma linha

ALE total (R$/ano) = custo de downtime  +  risco de breach

Duas pernas. Independentes. Cada uma defensável sozinha. O total é a soma — sem peso mágico, sem multiplicador escondido.

A diferença pro resto do mercado mora na perna 1: a gente usa dados de uptime reais do seu domínio, não benchmark de indústria. É por isso que ela só faz sentido com uptime e segurança na mesma plataforma. EcoTrust, GAT, Unxpose — fazem segurança. Não têm seu histórico de incidentes.

Perna 1 — Custo de downtime

downtime_cost = horas_de_incidente_observadas_365d × revenue_per_hour

Tradução em prosa: a gente soma a duração de cada incidente que o monitor de Uptime vinculado ao alvo registrou nos últimos 12 meses, e multiplica pela receita por hora que você declarou.

Dois inputs, ambos seus:

Se você não vincular monitor, essa perna fica em R$ 0. A gente não chuta. Não usa benchmark "varejo médio perde R$ X". O número precisa ser seu pra ser defensável diante da diretoria.

Como dimensionar revenue_per_hour se você não sabe de cabeça? Tem um post inteiro com calculadora em quanto custa uma hora de site fora do ar. Spoiler: o número costuma ser 3 a 5× a "receita perdida pura" quando você soma CAC desperdiçado, SEO penalizado e suporte sobrecarregado.

Perna 2 — Risco de breach

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

Essa perna é a clássica ALE atuarial: probabilidade vezes impacto. A diferença é de onde vem cada termo.

A tabela de probabilidades

A probabilidade anual de incidente vem do tier de risco do último audit do alvo (resultado do score contextualizado: nota técnica + criticidade de negócio + threat-intel KEV/EPSS). Tabela calibrada:

Por que esses números? Calibração baseada em literatura pública (Verizon DBIR, relatórios Ponemon) ajustada pro escopo do que a auditoria observa. É opinable — e por isso a tabela é uma constante explícita no código, não uma rede neural escondida. Se você tem dado próprio do seu setor, dá pra discutir. Mas a régua precisa ser a mesma entre alvos pra comparação fazer sentido.

Os inputs de impacto

São três campos que você preenche uma vez por workspace em Configurações → Risco financeiro:

Por que você preenche e não a gente? Porque quem conhece o negócio é você. A perna 1 é objetiva (dados nossos). A perna 2 é a sua visão sobre o seu impacto. Transparência > falsa precisão.

Exemplo completo

E-commerce de moda. Configuração:

• Monitor de Uptime: 6h12 de incidentes nos últimos 365 dias
• Receita/hora declarada: R$ 12.000
• Último audit: nota C, criticidade de negócio alta → risk_tier = high
• Settings → Risco financeiro:
  • lgpd_exposure: R$ 50.000
  • incident_recovery_cost: R$ 80.000
  • reputation_factor: 1.5

Cálculo:

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

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

ALE total                              = R$ 113.400/ano

Esse é o número que vai pra reunião com a diretoria. Não "12 highs em aberto" — R$ 113.400/ano de exposição esperada se nada for feito.

O que muda quando você corrige

Cada eixo se mexe diferente:

• Corrigir um finding crítico → derruba a nota técnica → derruba o risk_tier da perna 2 → a tabela de probabilidades muda 1 ou 2 degraus → breach_ale cai pra fração do que era.
• Vincular o monitor de uptime (se ainda não vinculou) → perna 1 sai de R$ 0 e fica honesta.
• Reduzir downtime real (HA, deploy melhor, CDN) → menos horas no período de 365 dias → perna 1 cai.
• Aumentar reputation_factor (cliente novo grande, SLA mais agressivo) → perna 2 sobe — você ajusta o número à realidade.

E o score técnico A–F continua intocável. Por design. Score técnico é régua de comparação entre alvos; risco financeiro é régua de priorização. São eixos paralelos, deliberadamente.

Threat intel ainda escala a probabilidade

Detalhe que muita gente perde: se o último audit detectou um finding com CVE listado no CISA KEV (catálogo de vulnerabilidades em exploração ativa) ou EPSS ≥ 0.5 (alta probabilidade de exploração nos próximos 30 dias), o risk_tier sobe um degrau automaticamente.

Na prática isso significa: um alvo medium com finding KEV vira high na hora — e o breach_ale salta de 8% × impacto para 20% × impacto. 2.5× o número de antes, sem nenhuma ação humana.

É a tradução em reais de "isso aqui não é teórico, está sendo explorado neste momento".

A leitura agregada do workspace

O número de cada alvo soma na visão de workspace. Pra agência ou time gerenciando 30 clientes, isso vira:

Exposição agregada do portfólio: R$ 2.847.000/ano em 14 ativos auditados.

Esse é o número que a diretoria vê. Quando você abre o detalhamento, vê quais alvos contribuem mais — e quais correções têm maior retorno em reais derrubados.

Onde isso vive no produto

• Card no Security/Show — exposição do alvo (perna 1 + perna 2 separadas + total).
• Dashboard de workspace — agregado, com top contributors.
• Relatório semanal — diff de exposição (subiu/desceu desde a última semana).
• PDF de auditoria — número aparece no relatório que vai pro cliente final / diretoria.

Como ativar agora (3 minutos)

1. Settings → Risco financeiro — habilite, preencha LGPD/recovery/reputation. Uma vez por workspace.
2. Security → editar alvo — preencha "Receita por hora" e selecione o monitor vinculado (auto-sugerido quando o host casa). Por alvo.
3. Rode uma auditoria (ou aguarde a semanal). O número aparece no card.

Se você já tem um monitor de Uptime no mesmo domínio: vamos pré-selecionar pra você ao editar o alvo. Se ainda não tem, crie o monitor primeiro — sem ele, a perna 1 fica zerada e o moat vira metade do que poderia ser.

Por que isso só faz sentido aqui

Toda ferramenta de ASM consegue calcular a perna 2 (probabilidade × impacto). Algumas até tentam estimar a perna 1 chutando "sites de e-commerce perdem em média R$ X/hora". Mas nenhuma delas tem o seu histórico de incidentes do último ano — porque nenhuma delas é também a sua ferramenta de uptime.

A gente é. É por isso que o número aparece. Não é estimativa de mercado — é a sua planilha.

Pra entender por que a nota técnica A–F não recebe o contexto financeiro (e por que isso é uma decisão de projeto, não esquecimento), leia pentest vs auditoria contínua. Pra dimensionar revenue_per_hour se você não tem o número de cabeça, vá em quanto custa uma hora de site fora do ar.