CISA KEV e EPSS: priorize vulnerabilidades na sua PME
Resposta direta: sua PME deve priorizar vulnerabilidades combinando três dimensões: evidência de exploração real, probabilidade de tentativa de exploração e contexto do ativo. O catálogo CISA KEV mostra vulnerabilidades conhecidas que já foram exploradas, enquanto o EPSS estima a probabilidade de tentativas de exploração nos próximos 30 dias. Nenhum dos dois substitui a análise do impacto no negócio. A decisão final precisa considerar exposição à internet, criticidade do sistema, dados processados, controles existentes e capacidade de recuperação.
Comece pelo risco explorado
Tratar todas as vulnerabilidades críticas como igualmente urgentes cria uma fila impossível para uma pequena ou média empresa. O volume cresce, a equipa perde foco e correções realmente importantes ficam misturadas com falhas que não estão expostas ou não afetam operações essenciais. Uma fila melhor começa com evidência objetiva: a vulnerabilidade está sendo explorada, tem probabilidade relevante de receber tentativas de exploração e está presente em um ativo que pode ser alcançado por um atacante?
O catálogo Known Exploited Vulnerabilities, conhecido como KEV, ajuda a responder à primeira parte. Uma entrada no catálogo indica que existe evidência de exploração conhecida. Para uma PME, isso deve elevar imediatamente a prioridade de investigação, mas não significa executar uma atualização às cegas. Primeiro é necessário confirmar a presença da vulnerabilidade, identificar os ativos afetados, entender a exposição e preparar uma correção que possa ser verificada.
Um servidor acessível pela internet, com uma vulnerabilidade presente no KEV e ligado a credenciais administrativas, merece tratamento antes de uma estação isolada com a mesma classificação técnica, mas protegida por controles adicionais. A classificação CVSS continua útil para descrever características técnicas e possíveis consequências. Porém, ela não informa sozinha se a falha já está sendo explorada, se o ativo está exposto ou se uma interrupção naquele sistema paralisaria a empresa.
A PME também deve separar prioridade de urgência operacional. Uma correção pode ser prioritária e ainda exigir janela de manutenção, cópia de segurança, validação do fornecedor e plano de reversão. Essa disciplina reduz o risco de transformar uma vulnerabilidade de segurança em indisponibilidade causada por uma atualização mal preparada.
Entenda KEV e EPSS
KEV e EPSS respondem a perguntas diferentes. O KEV aponta vulnerabilidades com exploração conhecida. O EPSS estima a probabilidade de que uma vulnerabilidade receba alguma tentativa de exploração nos próximos 30 dias. Essa probabilidade é dinâmica e deve ser registrada com a data da consulta, pois o valor pode mudar à medida que surgem novas informações, ferramentas ofensivas ou campanhas.
O EPSS não mede impacto, gravidade para a sua empresa nem probabilidade de comprometimento bem-sucedido. Um valor elevado não prova que o seu ambiente será invadido. Ele serve como sinal de atividade provável no ecossistema. O impacto continua dependendo do ativo, dos privilégios disponíveis, da arquitetura, dos dados acessíveis e dos controles de proteção. Da mesma forma, um valor baixo não deve ser usado para ignorar uma vulnerabilidade presente em um sistema essencial ou já listada no KEV.
Use os dois sinais como filtros complementares. Se a vulnerabilidade estiver no KEV, investigue e trate com prioridade porque existe evidência de exploração. Se não estiver no KEV, o EPSS ajuda a ordenar o grande conjunto restante. Em ambos os casos, aplique contexto local antes de definir prazo e ação. O objetivo não é obedecer mecanicamente a uma pontuação, mas reduzir primeiro as rotas de ataque que combinam probabilidade, exposição e consequência.
Também é importante não confundir ausência no KEV com ausência de risco. O catálogo é um insumo de priorização, não um inventário de todas as vulnerabilidades exploradas no mundo. Informações do fabricante, alertas setoriais, telemetria interna e inteligência de ameaças podem justificar prioridade mesmo quando uma falha ainda não aparece no catálogo.
Monte uma fila única
Crie uma fila central de vulnerabilidades em vez de manter listas separadas por ferramenta. Cada registro deve representar a combinação entre vulnerabilidade e ativo afetado. A mesma falha pode receber prioridades diferentes em dois equipamentos porque exposição, função, dados e controles são diferentes. Sem essa associação, a equipa corre o risco de corrigir um ativo secundário e deixar aberto o sistema realmente importante.
| Sinal | Pergunta prática | Uso na decisão |
|---|---|---|
| KEV | Existe exploração conhecida? | Elevar a prioridade de confirmação e correção. |
| EPSS | Há maior probabilidade de tentativas nos próximos 30 dias? | Ordenar vulnerabilidades que ainda não estão no KEV. |
| Exposição | O ativo pode ser alcançado pela internet ou por redes não confiáveis? | Aumentar a urgência e considerar mitigação imediata. |
| Criticidade | Uma falha afeta receita, operação, identidade ou dados sensíveis? | Definir impacto e janela máxima de tratamento. |
| Controles | Segmentação, MFA, EDR ou filtragem reduzem a rota de ataque? | Ajustar a urgência sem eliminar a necessidade de correção. |
| Recuperação | Há backup, reversão e responsável pelo serviço? | Planejar uma mudança segura e verificável. |
Uma regra simples pode organizar a triagem. Coloque primeiro vulnerabilidades no KEV presentes em ativos expostos ou críticos. Depois, avalie as demais entradas do KEV. Em seguida, ordene as vulnerabilidades não listadas usando EPSS, exposição e importância do ativo. Por fim, mantenha as restantes em acompanhamento, com revisão periódica, porque os sinais e o contexto podem mudar.
Evite limites numéricos universais copiados de outra organização. Uma PME com poucos servidores expostos pode revisar todos eles rapidamente, enquanto outra possui ambiente distribuído e precisa de faixas operacionais. Defina critérios compatíveis com a sua capacidade, documente exceções e ajuste o processo com base no tempo real de correção e nos incidentes observados.
Aplique contexto da PME
O contexto começa com inventário confiável. A equipa precisa saber quem é responsável pelo ativo, qual serviço ele sustenta, onde está exposto, quais versões estão instaladas e que dependências podem ser afetadas. Se o inventário estiver incompleto, use descoberta de ativos, registros de autenticação, dados do firewall e agentes de monitorização para reduzir os pontos cegos.
Para consolidar eventos e relacionar vulnerabilidades com atividade suspeita, vale entender como um SIEM centraliza sinais de segurança. A visibilidade melhora a decisão: uma vulnerabilidade detectada em um ativo que também apresenta tentativas de autenticação, execução anômala ou comunicação incomum exige resposta mais rápida do que uma ocorrência sem sinais associados.
Nos endpoints e servidores, agentes podem fornecer inventário, versões, alertas e evidências para confirmar se a correção funcionou. O guia de implantação dos agentes Wazuh em PMEs ajuda a estruturar essa cobertura sem perder de vista testes, grupos de ativos e responsabilidade operacional.
Ao avaliar consequência, faça perguntas concretas. O comprometimento permitiria acesso a contas administrativas? O ativo contém dados pessoais, financeiros ou de clientes? A exploração poderia interromper faturação, atendimento ou produção? Existe comunicação direta com backups ou sistemas de identidade? Essas respostas transformam uma pontuação genérica em uma decisão adequada à realidade da empresa.
Controles compensatórios devem ser específicos e temporários. Remover a exposição pública, bloquear uma rota vulnerável, restringir acesso por VPN, segmentar a rede ou desativar uma funcionalidade pode reduzir o risco enquanto a atualização é preparada. Registre responsável, evidência, prazo e condição de encerramento. Uma mitigação sem validade definida tende a virar uma exceção permanente e invisível.
Execute e verifique correções
A correção só termina quando sua instalação e seu efeito são verificados. Marcar um chamado como concluído depois de enviar um comando de atualização não confirma que todos os ativos receberam o pacote, reiniciaram corretamente ou deixaram de expor a versão vulnerável. O processo precisa guardar evidências antes e depois da mudança.
- Confirme a ocorrência: valide produto, versão, configuração e ativo afetado para evitar trabalho sobre um falso positivo.
- Defina a prioridade: combine KEV, EPSS, exposição, criticidade, sinais internos e controles existentes.
- Escolha o tratamento: aplique patch, upgrade, alteração de configuração, isolamento ou mitigação temporária documentada.
- Prepare a mudança: registre backup, dependências, teste, responsável, janela de manutenção e procedimento de reversão.
- Implemente por etapas: quando possível, comece por um grupo controlado antes de alcançar todos os sistemas semelhantes.
- Verifique o resultado: repita a detecção, confira versão e configuração, valide a saúde do serviço e procure erros.
- Monitore depois: acompanhe alertas, comportamento do ativo e possíveis tentativas relacionadas à vulnerabilidade.
Se a correção falhar, a fila deve voltar automaticamente ao estado de ação necessária, sem perder o histórico. Registre por que falhou: pacote incompatível, dispositivo offline, dependência, falta de espaço, janela encerrada ou impacto inesperado. Esses motivos orientam melhorias e mostram onde automação ou documentação podem reduzir o tempo de exposição.
Exceções precisam de aprovação, justificativa e data de revisão. A aceitação de risco não deve apagar a vulnerabilidade do painel. Ela deve mostrar claramente o ativo, a decisão, o responsável, os controles compensatórios e o prazo. Quando o KEV, o EPSS ou a exposição mudarem, a exceção precisa ser reavaliada.
Para começar sem um programa complexo, escolha os ativos expostos à internet e os sistemas de identidade, consolide as vulnerabilidades por ativo e aplique o fluxo semanalmente. Meça cobertura do inventário, tempo até confirmação, tempo até correção e quantidade de falhas reabertas após verificação. A maturidade vem da repetição consistente, não da criação de uma fórmula perfeita no primeiro dia.
Fontes
- CISA: orientação para usar o catálogo KEV como insumo para a estrutura de priorização de vulnerabilidades, combinando a evidência de exploração conhecida com o processo de gestão da organização.
- FIRST: definição do EPSS como forma de estimar a probabilidade de observar tentativas de exploração nos próximos 30 dias, sem tratar essa probabilidade como medida de impacto.
- NIST: gestão de patches como processo de identificar, priorizar, adquirir, instalar e verificar a instalação de patches, atualizações e upgrades em toda a organização.