Um sistema de monitoramento de CVE em tempo real não exige orçamentos milionários nem equipes de 50 pessoas. Com o feed JSON do NVD, ferramentas open-source como Nuclei ou OpenVAS e uma priorização inteligente (CVSS + EPSS), uma equipe pequena pode filtrar o ruído e focar no crítico. Aqui está a arquitetura testada que usamos na CyberShield para PMEs da América Latina, com pipeline de alertas que não satura o SOC.

Por que o feed JSON do NVD é a base (e o que não te contam sobre ele)?

O feed JSON do NVD é o padrão de fato para monitorar vulnerabilidades, mas sua adoção direta tem armadilhas ocultas. Primeiro, o volume: em 2023, o NVD publicou 28.902 CVE (fonte: NIST NVD Annual Report 2023), 18% a mais que no ano anterior. Segundo, a latência: embora o feed seja atualizado a cada 2 horas, a atribuição de CVSS e CPE pode demorar dias (ou semanas) para vulnerabilidades complexas. Terceiro, a granularidade: o campo configurations no JSON usa CPE 2.3, que nem sempre mapeia de forma limpa com os ativos reais de uma PME.

A solução não é descartar o NVD, mas complementá-lo. Na CyberShield, usamos o feed JSON como source of truth, mas o enriquecemos com:

O pipeline básico que recomendamos:

  1. Baixar o feed JSON do NVD a cada 2 horas via curl ou um cron job.
  2. Filtrar por CPEs relevantes usando jq ou um script Python (exemplo: jq '.CVE_Items[] | select(.configurations.nodes[].cpe_match[].cpe23Uri | contains("apache:tomcat"))').
  3. Enriquecer com dados do KEV e EPSS (mais sobre isso na seção de priorização).
  4. Armazenar em um banco de dados leve como SQLite ou PostgreSQL para consultas posteriores.

Priorização: CVSS + EPSS + contexto local (a fórmula que reduz o ruído em 80%)

O CVSS é útil, mas insuficiente. Uma CVE com CVSS 10.0 em um software obsoleto que você não usa é ruído. Uma CVE com CVSS 7.5 no seu banco de dados principal é crítica. É aqui que entra o EPSS (Exploit Prediction Scoring System), desenvolvido pela FIRST, que estima a probabilidade de uma CVE ser explorada nos próximos 30 dias.

A literatura disponível sugere que combinar CVSS e EPSS melhora a priorização. Um estudo da Kenna Security (2021) descobriu que 80% das CVEs com EPSS > 0,8 foram exploradas na natureza, enquanto apenas 5% das CVEs com EPSS < 0,2 o foram. Na CyberShield, usamos esta matriz de priorização:

CVSS \ EPSS EPSS < 0,2 0,2 ≤ EPSS < 0,5 EPSS ≥ 0,5
CVSS < 7,0 Baixa prioridade (revisão trimestral) Prioridade média (revisão mensal) Prioridade alta (revisão semanal)
7,0 ≤ CVSS < 9,0 Prioridade média (revisão mensal) Prioridade alta (revisão semanal) Crítica (revisão imediata)
CVSS ≥ 9,0 Prioridade alta (revisão semanal) Crítica (revisão imediata) Crítica (revisão imediata + mitigação em 24h)

Mas mesmo essa matriz tem limitações. Por exemplo, uma CVE com CVSS 9,8 e EPSS 0,9 em um servidor exposto à internet deve ser tratada como incidente, não como mais uma alerta. Por isso, adicionamos duas camadas adicionais:

  1. Exposição de ativos: Usamos ferramentas como nmap ou masscan para mapear quais ativos estão expostos à internet. Uma CVE em um ativo interno sem acesso externo desce automaticamente um nível na matriz.
  2. Exploits públicos: Consultamos bancos de dados como Exploit-DB ou GitHub Trickest CVE para verificar se há exploits públicos disponíveis. Se houver, a CVE sobe um nível.

Resultado: em um cliente com 50 ativos, passamos de 1.200 alertas mensais para 45, das quais apenas 5 exigiam ação imediata.

Ferramentas open-source para varredura: Nuclei vs. OpenVAS (e por que escolhemos uma)

Uma vez priorizadas as CVEs, o próximo passo é verificar se estão presentes em sua infraestrutura. Aqui há duas ferramentas open-source dominantes: OpenVAS (agora parte do Greenbone) e Nuclei (do ProjectDiscovery). Ambas têm vantagens e trade-offs.

OpenVAS: o veterano com profundidade (mas lento)

O OpenVAS é um scanner de vulnerabilidades maduro, com mais de 50.000 testes em seu banco de dados. Suas vantagens:

Mas também tem desvantagens:

Nuclei: o ágil com templates personalizáveis (mas com menos cobertura)

O Nuclei é um scanner baseado em templates YAML, projetado para ser rápido e modular. Suas vantagens:

Suas desvantagens:

Nossa escolha: Nuclei + varreduras seletivas do OpenVAS

Na CyberShield, usamos uma abordagem híbrida:

  1. Nuclei para varreduras diárias: Executamos o Nuclei todas as noites em modo "fast scan" para detectar CVEs críticas em ativos expostos à internet. Os templates são atualizados automaticamente do repositório do ProjectDiscovery.
  2. OpenVAS para varreduras semanais profundas: Uma vez por semana, executamos o OpenVAS em modo "deep scan" em ativos internos ou críticos. Isso nos dá cobertura para CVEs que o Nuclei poderia ter deixado passar.
  3. Templates personalizados para ativos críticos: Para servidores de bancos de dados ou aplicações legadas, escrevemos templates personalizados no Nuclei para detectar vulnerabilidades específicas.

Essa abordagem nos oferece o melhor dos dois mundos: velocidade para detecção precoce e profundidade para cobertura completa.

Pipeline de alertas: como evitar a fadiga do SOC

Um sistema de monitoramento de CVE não serve para nada se as alertas saturarem a equipe. Em um cliente com 200 ativos, passamos de 300 alertas diárias para 2-3, com estas técnicas:

1. Agrupamento por ativo e tipo de vulnerabilidade

Em vez de enviar uma alerta para cada CVE, agrupamos por:

2. Contexto nas alertas (não apenas "CVE-2023-1234 detectada")

Uma alerta útil inclui:

Exemplo de alerta real que enviamos:

Alerta crítica: CVE-2023-46604 no servidor-web-01 (192.168.1.10)

CVE: CVE-2023-46604 (CVSS: 9,8, EPSS: 0,95)

Exposição: Exposto à internet na porta 8080 (Apache ActiveMQ).

Exploits públicos: Sim (módulo Metasploit disponível).

Recomendação: Atualizar para ActiveMQ 5.15.16 ou aplicar patch temporário (ver link).

Ações tomadas: O servidor foi isolado da rede interna como medida temporária.

3. Escalonamento automático baseado em prioridade

Usamos um sistema de escalonamento em três níveis:

  1. Prioridade baixa/média: São registradas em um dashboard (Grafana) e revisadas na reunião semanal de segurança.
  2. Prioridade alta: É enviada uma alerta por Slack/Teams para a equipe de segurança, com SLA de 24 horas para revisão.
  3. Prioridade crítica: É enviada uma alerta por Slack/Teams e SMS para o responsável de plantão, com SLA de 1 hora. Além disso, é aberto automaticamente um ticket no Jira com prioridade "Highest".

4. Integração com ferramentas de ticketing e resposta

Para evitar trabalho manual, integramos o pipeline com:

Caso real: como detectamos e mitigamos a CVE-2023-46604 em 3 horas

Em 27 de outubro de 2023, a Apache anunciou CVE-2023-46604, uma vulnerabilidade de Remote Code Execution no ActiveMQ com CVSS 9,8. Veja como nosso sistema a tratou:

1. Detecção (Hora 0:00)

2. Priorização (Hora 0:05)

3. Verificação (Hora 0:30)

4. Mitigação (Hora 1:30)

5. Correção definitiva (Hora 3:00)

Tempo total desde a publicação da CVE até a mitigação: 3 horas. Sem esse sistema, o cliente teria demorado dias para detectar e corrigir a vulnerabilidade, tempo suficiente para que um atacante explorasse o RCE.

Erros comuns (e como evitá-los)

Em nossa experiência implementando esses sistemas em PMEs da América Latina, estes são os erros mais frequentes:

1. Confiar apenas no CVSS

O CVSS é um bom ponto de partida, mas não considera o contexto. Por exemplo, uma CVE com CVSS 10,0 em um software que você não usa não é crítica. Sempre combine CVSS com EPSS e exposição de ativos.

2. Não atualizar o inventário de ativos

Um sistema de monitoramento de CVE é tão bom quanto seu inventário de ativos. Se você não sabe qual software tem, não poderá filtrar as CVEs relevantes. Use ferramentas como osquery ou inventory.sh para manter o inventário atualizado automaticamente.

3. Escanear tudo, o tempo todo

Varreduras profundas como as do OpenVAS consomem muitos recursos e podem afetar a disponibilidade dos sistemas. Foque em ativos críticos e use varreduras leves (como o Nuclei) para o restante.

4. Não integrar com o fluxo de trabalho da equipe

Se as alertas não chegam à equipe certa no formato certo, não servirão para nada. Certifique-se de integrar o pipeline com as ferramentas que a equipe já usa (Slack, Jira, etc.).

5. Ignorar as CVEs "antigas"

Muitas equipes se concentram apenas nas CVEs novas, mas as antigas continuam sendo exploradas. Por exemplo, a CVE-2017-5638 (Apache Struts) ainda é uma das vulnerabilidades mais exploradas em 2023 (fonte: CISA KEV). Certifique-se de que seu sistema também monitore CVEs antigas em seus ativos.

6. Não testar os patches antes de aplicá-los

Um patch mal aplicado pode quebrar uma aplicação crítica. Sempre teste os patches em um ambiente de staging antes de aplicá-los em produção.

Na CyberShield, documentamos esses erros (e como evitá-los) em nossa base de conhecimento interna, que compartilhamos com nossos clientes para que não repitam os mesmos equívocos.

Monitorar CVEs em tempo real não é mágica: é um processo sistemático que combina feeds de vulnerabilidades, priorização inteligente, ferramentas open-source e um pipeline de alertas bem projetado. Com a arquitetura que descrevemos aqui, uma equipe pequena pode reduzir o ruído, focar no crítico e responder às ameaças em horas, não em dias. A chave está em automatizar o repetitivo, integrar as ferramentas com os fluxos de trabalho existentes e, acima de tudo, não subestimar o poder de um inventário de ativos atualizado.

Em um ambiente onde o tempo entre a publicação de uma CVE e sua exploração é medido em horas, a diferença entre um sistema eficaz e um ineficaz pode ser a sobrevivência de sua infraestrutura. A equipe da CyberShield continua refinando esses processos para PMEs da América Latina, porque sabemos que a cibersegurança não é um luxo: é uma necessidade operacional.

Fontes

  1. NIST National Vulnerability Database (NVD). (2023). NVD Annual Report 2023. https://nvd.nist.gov/general/news/annual-report-2023
  2. FIRST. (2023). Exploit Prediction Scoring System (EPSS) v3.0. https://www.first.org/epss/
  3. Kenna Security. (2021). The EPSS Model: A New Way to Measure Vulnerability Risk. https://www.kennasecurity.com/blog/the-epss-model-a-new-way-to-measure-vulnerability-risk/
  4. CISA. (2023). Known Exploited Vulnerabilities Catalog Annual Report. https://www.cisa.gov/sites/default/files/2023-11/KEV_Annual_Report_2023.pdf
  5. Apache Software Foundation. (2023). CVE-2023-46604 Security Advisory. https://activemq.apache.org/security-advisories.data/CVE-2023-46604-announcement.txt
  6. ProjectDiscovery. (2023). Nuclei Templates Repository. https://github.com/projectdiscovery/nuclei-templates
  7. Greenbone Networks. (2023). OpenVAS Documentation. https://www.openvas.org/
  8. NIST. (2020). NIST Special Publication 800-40 Revision 3: Guide to Enterprise Patch Management Technologies. https://csrc.nist.gov/publications/detail/sp/800-40/rev-3/final
  9. MITRE. (2023). Common Vulnerabilities and Exposures (CVE) List. https://cve.mitre.org/
  10. Exploit-DB. (2023). Offensive Security Exploit Database. https://www.exploit-db.com/