Como Escrevo um Risk Finding que o Negócio Vai Agir?

A maioria dos achados de segurança morre em uma planilha porque são escritos para outras pessoas de segurança, não para quem aprova o orçamento. Se seu relatório diz "CVE-2023-XXXX, CVSS 9.8, aplique patch imediatamente," você descreveu uma vulnerabilidade, não um risco. O negócio não age sobre vulnerabilidades. Ele age sobre consequências que consegue imaginar.

Por que scores de severidade sozinhos não movem ninguém

CVSS diz o quão ruim é uma falha em isolamento. Não diz nada sobre se essa falha é alcançável, se o ativo atrás dela importa para receita, ou se controles compensatórios já a atenuam. Um 9.8 em uma máquina de dev interna sem caminho para internet e sem dados sensíveis não é a mesma conversa que um 7.5 no gateway de pagamento. Se você classifica achados puramente por CVSS vai gastar sua credibilidade corrigindo coisas que ninguém nunca teria explorado, e o achado que realmente importava se perde no ruído.

Risk que é efetivamente tratado tem três ingredientes: um caminho plausível para impacto, um custo em dólares ou operacional ligado a esse impacto, e um proprietário que realmente consegue corrigi-lo. Perca qualquer um desses e o achado fica no backlog.

Construa o achado em torno de um cenário, não de uma saída de scanner

Em vez de "SQL injection encontrado em /login endpoint," escreva o cenário: "Um atacante não autenticado pode extrair a tabela completa de clientes, incluindo senhas em hash e endereços de cobrança, através do formulário de login. Esta tabela suporta 40.000 contas ativas e o mesmo banco de dados contém histórico de pedidos ligado ao escopo PCI." Agora o leitor não está analisando uma classe de vulnerabilidade, está imaginando uma carta de notificação de breach e uma chamada de compliance.

Uma estrutura útil para cada achado:

• O que pode acontecer — o caminho de ataque em linguagem clara, uma ou duas frases.
• O que toca — sistema específico, dados específicos, processo de negócio específico.
• O que custa — horas de downtime, exposição regulatória, confiança do cliente, penalidades contratuais. Use números reais onde você tem (cláusulas de penalidade SLA, custos de incidentes passados, franquia de seguro cibernético).
• O que leva para corrigir — esforço, não apenas "aplique patch." Às vezes a correção é uma regra WAF hoje e uma mudança de código no próximo sprint.
• Quem é dono da correção — um nome ou um time, não "TI."

Conecte o achado a algo que o negócio já acompanha

Toda empresa tem métricas que a liderança já observa: SLAs de uptime, churn, achados de auditoria do último ciclo SOC 2, prêmios de seguro cibernético, um contrato de cliente específico com cláusula de segurança. Se você conseguir conectar seu achado a uma daquelas linhas já existentes — "esta é a mesma classe de issue que nosso segurador sinalizou na última renovação" ou "este fluxo de dados está no escopo para a auditoria SOC 2 em Q3" — você não está pedindo para eles se importarem com algo novo. Você está mostrando uma ameaça a algo pelo qual eles já são responsáveis.

Este também é o lugar onde conversar com o lado do negócio compensa antes de você finalizar o relatório. Uma conversa de dez minutos com finanças ou operações sobre o que um outage de quatro horas em um sistema específico realmente custa bate qualquer linha genérica de "dano reputacional." Consiga o número, cite-o, siga em frente.

Classifique por exploitabilidade e blast radius, não apenas CVSS

Uma abordagem de priorização viável:

1. É alcançável pela internet ou requer acesso interno primeiro?
2. Há um exploit público ou é teórico?
3. Toca dados regulados (PCI, PHI, PII) ou sistemas de joia da coroa?
4. Qual é o tempo e custo reais para remediar versus o custo de deixar como está?

Achados que pontuam alto em reachability e blast radius mas apenas médio em CVSS frequentemente merecem pular a fila sobre um bug crítico enterrado três hops de rede atrás de um jump box com MFA.

Escreva o pedido, não apenas o problema

Termine cada achado com uma solicitação específica: uma linha de orçamento, uma janela de mudança, uma exceção de política para fechar, ou uma decisão nomeada necessária até uma data. "Recomendamos remediação" é ignorado. "Precisamos de uma janela de manutenção de quatro horas antes do dia 15 para fazer patch do gateway de pagamento, ou aceitamos o risco residual por escrito" força uma decisão de um jeito ou de outro. Dar à liderança uma opção explícita de aceitar-o-risco, por escrito, com o nome deles nela, frequentemente é o que finalmente consegue a correção aprovada.

Se você quer praticar transformar saída bruta de scan em achados como este, trabalhe através dos segmentos Blue Team e Offensive da Korra Studio juntos — combinar contexto de exploração com drills de relatório é onde essa habilidade realmente se afina.