Antes do próximo KEV: descubra o ativo que o CMDB ainda não conhece

O sinal e os factos que mudam a decisão

A velocidade das novas entradas KEV torna insuficiente começar o inventário depois do anúncio. Serviços expostos, appliances, ambientes de laboratório e ferramentas de dados podem não aparecer no CMDB que alimenta a equipa de patching.

KEV prioriza exploração observada; a organização ainda precisa de resolver produto, versão, configuração e exposição. Descoberta externa não vê serviços internos e inventário de endpoint não vê SaaS ou appliances sem agente.

Um desconhecido precisa de owner e prazo; não deve ser convertido automaticamente em não afetado. O ativo mais perigoso pode ser precisamente o que não tem owner, agente de gestão ou registo de compra.

Decisão, limites e condição de bloqueio

Reconcile pelo menos três vistas independentes — inventário declarado, descoberta interna e superfície externa — antes de afirmar ausência.

O ativo mais perigoso pode ser precisamente o que não tem owner, agente de gestão ou registo de compra.

Execução e prova de conclusão

A execução deve começar por comparar cmdb, dns, certificados, cloud, edr, scanners e contas de fornecedor. Depois, criar regras de reconciliação e fila explícita para ativos sem correspondência. O fecho exige atribuir owner, criticidade, exposição e método de prova a cada ativo novo.

Medir cobertura por fonte, ativos exclusivos, ativos sem owner e tempo até identificação depois de uma entrada KEV.

• comparar CMDB, DNS, certificados, cloud, EDR, scanners e contas de fornecedor.
• criar regras de reconciliação e fila explícita para ativos sem correspondência.
• atribuir owner, criticidade, exposição e método de prova a cada ativo novo.
• Medir cobertura por fonte, ativos exclusivos, ativos sem owner e tempo até identificação depois de uma entrada KEV.