White PaperSaber que o ativo existe não é o mesmo que saber o que está nele
Coleta agentless de contexto profundo em 11 categorias
Inventário superficial diz que o ativo existe. Inventário profundo diz o que está nele. O Inventory coleta software com versão, patches, SBOM CPE 2.3, hardening CIS e 30+ checks por host via WMI e SSH, sem agente, para que VulScan e GVul operem com precisão.
O problema: a maioria dos inventários de ativos captura dados superficiais, IP, hostname, sistema operacional, tipo de dispositivo. Esses dados dizem que o ativo existe. Não dizem o que está instalado nele, qual versão, quais patches foram aplicados, quem tem acesso, como está configurado em relação a benchmarks de segurança. Sem esse contexto, é impossível avaliar o risco real de cada ativo.
A abordagem: o EcoTrust Inventory coleta dados profundos de 11 categorias por ativo, software instalado com versões, patches aplicados, configurações de hardware, usuários, serviços, rede, segurança, SBOM CPE 2.3, hardening CIS Benchmark e alertas de AD. Tudo via protocolo nativo (WMI/WinRM para Windows, SSH para Linux e macOS) sem instalar agente nos endpoints.
O resultado: cada ativo transforma-se em uma entidade de risco avaliável com contexto completo, software instalado, versões exatas, patches aplicados, configurações de segurança, usuários e SBOM. O inventário profundo já é, por si só, uma das maiores fontes de informação para decisões de segurança. Esses dados também alimentam o VulScan para correlação precisa de CVEs, o GVul para priorização por criticidade e o CRQ para quantificação financeira.
O ativo está no mapa. Mas o que está nele?
O Discovery encontrou o ativo. Agora vem a pergunta que muda tudo: o que está instalado nesse servidor? Qual versão do Apache? O OpenSSL está atualizado? Quem tem acesso? A configuração segue o CIS Benchmark?
Um servidor com IP 192.168.1.100 e hostname "srv-prod-01" identificado pelo Discovery é, nesse momento, apenas um ponto no mapa. Para transformá-lo em uma entidade de risco gerenciável, que pode ser escaneada, priorizada, remediada e auditada, é preciso contexto profundo sobre o que está dentro.
Esse contexto é o que diferencia gestão de vulnerabilidades eficaz de gestão de vulnerabilidades que parece eficaz. Um scanner que detecta CVE-2024-38024 em "Apache HTTP Server" precisa saber que a versão instalada naquele servidor é a 2.4.51, vulnerável, e não a 2.4.62, corrigida. Sem o inventário de software com versões precisas, o scanner opera com aproximações que produzem falsos positivos e, pior, falsos negativos.
O que falta no inventário superficial, e por que isso importa.
Inventário superficial captura o que o ativo é. Inventário profundo captura o que o ativo contém e como está configurado. A diferença não é cosmética, define a qualidade de cada decisão de segurança tomada a partir desse dado.
O problema da versão imprecisa: um scanner que sabe que o ativo tem "Apache instalado", mas não sabe que a versão é 2.4.51, não consegue determinar com certeza se a CVE-2021-41773 (path traversal crítico) se aplica. Ou reporta o ativo como vulnerável (falso positivo se a versão for 2.4.51+) ou não reporta (falso negativo se for 2.4.49). Sem versão precisa, cada CVE vira uma incerteza.
Os cinco gaps críticos do inventário superficial
Saber que "Python está instalado" não diz nada. Saber que é Python 3.8.10 em um servidor de produção significa que há CVEs aplicáveis, que é uma versão em EOL desde outubro de 2024 e que precisa de atualização urgente. A versão exata é o que conecta o ativo ao banco de CVEs.
Saber que um servidor "tem Windows instalado" sem saber quais KBs foram aplicadas é equivalente a não saber nada sobre o estado de segurança. O Patch Management só pode operar com eficácia quando sabe exatamente quais patches estão ausentes, e isso exige uma lista precisa de KBs instaladas.
Quem tem acesso ao servidor de banco de dados de produção? Há contas locais além das contas de domínio? Usuários com privilégios excessivos são um dos vetores mais comuns de escalada de privilégio, e são invisíveis em inventários superficiais.
O servidor tem firewall ativo? Auditoria de segurança habilitada? Protocolo SMBv1 desativado? Sem verificação ativa contra um benchmark de segurança como o CIS, não é possível saber se o ativo está configurado de forma segura, apenas que existe.
Uma aplicação Python pode ter 87 dependências de pacotes, cada uma potencialmente com vulnerabilidades próprias. Sem um SBOM (Software Bill of Materials) preciso, vulnerabilidades em bibliotecas como Log4j, OpenSSL ou requests ficam invisíveis até um incidente.
A abordagem de contexto profundo, cada ativo como entidade de risco completa.
Contexto profundo significa que cada ativo, após o Inventory, tem dados suficientes para ser avaliado, priorizado, gerenciado e auditado sem depender de coletas manuais adicionais.
O Inventory transforma o ativo de um ponto no mapa em uma entidade rica em dados. Não apenas "o ativo existe e está rodando Windows Server 2019", mas "o ativo tem 247 pacotes instalados, 12 patches ausentes, 3 usuários com privilégios de administrador local, configuração CIS com 8 falhas em 34 checks, e o serviço RDP está habilitado".
Com esse contexto, o VulScan pode correlacionar CVEs com precisão. O GVul pode priorizar considerando o que o ativo contém. O CRQ pode calcular o impacto financeiro de um comprometimento baseado no que está em risco. O Patch Management pode identificar exatamente quais patches aplicar.
A cadeia que o Inventory habilita: Discovery entrega o mapa de ativos. Inventory preenche o contexto profundo. VulScan correlaciona CVEs com precisão. GVul prioriza por risco real. Patch Management valida a remediação. O Inventory é o elo que conecta a descoberta de ativos à gestão eficaz de vulnerabilidades.
Como o Inventory opera, agentless, profundo e completo.
O Inventory coleta dados via protocolos nativos de gerenciamento remoto: WMI e WinRM para Windows, SSH para Linux e macOS. Nenhum agente é instalado nos endpoints, a mesma sessão autenticada usada pelo time de TI para gerenciar os servidores é usada pelo Inventory para coletar os dados.
As 11 categorias de dados coletadas
Arquitetura agentless, zero footprint nos endpoints
A coleta via WMI/WinRM e SSH usa as mesmas permissões de gerenciamento remoto já configuradas pelo time de TI. Nenhum processo permanente fica rodando no endpoint após a coleta, zero conflito com soluções de EDR, zero exceções de segurança necessárias.
As credenciais do Inventory são as mesmas já cadastradas pelo time de TI para gerenciamento remoto. Se o time já acessa os servidores via WinRM para administração, o Inventory está pronto para operar com as mesmas credenciais, sem contas adicionais, sem configurações novas.
Impacto no negócio, o que o contexto profundo habilita.
O Inventory não entrega apenas dados, entrega a base sobre a qual todo o programa de segurança subsequente opera com precisão.
VulScan com zero falsos negativos por versão imprecisa
O VulScan usa a lista de software do Inventory com versões exatas para gerar identificadores CPE 2.3 e correlacioná-los com a base NVD. Com versões precisas, a correlação é exata: a CVE se aplica ou não se aplica, sem "possível" ou "provável". A redução de falsos positivos e negativos é direta.
Priorização real no GVul com criticidade do ativo
O GVul usa a classificação de criticidade do ativo para ponderar a priorização. Um servidor de banco de dados de produção identificado pelo Inventory como crítico recebe tratamento diferente de um servidor de testes. Sem o contexto do Inventory, o GVul não tem como distinguir os dois, e a priorização se torna genérica.
Hardening CIS como baseline documentada
Os 30+ checks de CIS Benchmark do Inventory transformam a configuração de segurança de cada ativo de uma propriedade implícita para uma propriedade explicitamente documentada. O CISO sabe quantos ativos falham no check de "SMBv1 desabilitado" ou "auditoria de segurança habilitada", e pode acompanhar a evolução ao longo do tempo.
SBOM e Log4j: quando Log4j virou o maior incidente de segurança de 2021 a 2022, organizações com SBOM preciso identificaram em horas quais servidores tinham a biblioteca afetada. Organizações sem SBOM levaram dias ou semanas, vasculhando servidores manualmente. O SBOM CPE 2.3 do Inventory é exatamente o que resolve esse problema estruturalmente.
Compliance, o inventário que os auditores precisam ver.
O Inventory entrega exatamente o inventário de software com versão precisa exigido pelo Controle 2, atualizado a cada execução e com histórico auditável.
O Inventory fornece as versões precisas de software necessárias para que a gestão de vulnerabilidades do A.8.8 seja eficaz, sem versões precisas a correlação de CVEs é imprecisa.
O inventário de software com versões exatas e lista de patches aplicados atende diretamente ao requisito 6.3 de rastreabilidade de software e patches em ambientes PCI.
O Inventory identifica quais ativos processam dados pessoais pelo contexto de software e configuração, e os checks de CIS Benchmark documentam as medidas técnicas aplicadas.
Conclusão, contexto é a diferença entre gestão e ilusão de gestão.
Um scanner de vulnerabilidades que não sabe o que está em cada ativo não está gerenciando vulnerabilidades. Está produzindo relatórios com graus variáveis de imprecisão.
A gestão eficaz de vulnerabilidades depende de saber com exatidão: qual software está instalado, em qual versão, com quais patches, em um ativo de qual criticidade, acessado por quais usuários, com qual configuração de segurança. Sem esse contexto, cada CVE é uma hipótese, não uma certeza.
O EcoTrust Inventory entrega esse contexto de forma agentless, profunda e em 11 categorias, transformando cada ativo de um ponto no mapa em uma entidade de risco completamente avaliável que alimenta todo o ciclo de gestão de risco da plataforma com dados precisos.
Veja o contexto profundo dos seus ativos.
Demonstração ao vivo