INS.1 - Inventário de Ativos Corporativos

Nota do grupo INS (Inventário e Superfície de Ataque) do Framework CTH, derivada do Capítulo 5 do PDF de referência. Este controle é o fundamento material de todo o programa integrado de CTI e Threat Hunting.
Papel no programa: definir o universo de ativos sobre o qual se calcula exposição, se formulam hipóteses de caça, se priorizam remediações e se executam respostas a incidentes.

1. Contexto e Posicionamento no Framework CTH

O grupo INS é a base estrutural do Framework CTH, e o INS.1 é a base do próprio grupo. A premissa é direta: não se protege e não se caça no que não se conhece. Sem um inventário abrangente e atualizado, a CTI não consegue avaliar a relevância real de uma ameaça para o ambiente, o Threat Hunter perde o mapa mínimo para delimitar o escopo de cada caça e a resposta a incidentes começa cada investigação tentando adivinhar do que a organização é feita.

A experiência de mercado dimensiona o problema. Organizações tipicamente desconhecem entre 20% e 40% dos ativos conectados à própria rede, e o percentual cresce quando se incluem workloads em nuvem, ambientes efêmeros de homologação e dispositivos móveis. Adversários exploram exatamente essa lacuna: ativos não gerenciados (shadow IT) e infraestrutura órfã, sem dono e sem manutenção, são pontos de entrada recorrentes em campanhas de intrusão direcionadas, justamente porque não recebem correções, não têm agente de segurança e não geram telemetria.

O controle tem lastro também em modelos de mercado consolidados. O inventário de ativos é o primeiro controle do CIS Controls v8 e ocupa posição central na função Identify do NIST CSF 2.0, o que reflete um consenso: toda decisão de segurança, da priorização de vulnerabilidades ao desenho de detecções, depende de saber o que existe. No Framework CTH, o INS.1 define a unidade mínima de análise, o ativo, sobre a qual os controles INS.2 a INS.5 constroem camadas sucessivas de conhecimento.

2. Conceito e Propriedades de um Inventário Útil

Um inventário de ativos corporativos é um repositório estruturado, consultável e continuamente verificado de todos os elementos de TI, OT e IoT que compõem o ambiente. Mais do que uma lista, é um modelo de dados que responde perguntas operacionais em segundos: quais servidores expõem determinado serviço, quem é o dono de um ativo, qual a criticidade de negócio de um host, quantos endpoints ainda executam um sistema sem suporte. A ausência dessas respostas transforma cada alerta em investigação arqueológica.

A diferença entre um inventário útil e uma planilha estática está em três propriedades. Cobertura significa incluir nuvem, on-premises, OT e mobile, e não apenas as estações corporativas gerenciadas. Atualidade significa que um ativo desativado sai do inventário e um ativo novo entra nele em horas, e não em meses. Contexto significa que cada registro carrega os atributos necessários para priorização, como dono, criticidade e localização.

3. Fontes de Descoberta e Coleta

Nenhuma fonte única cobre o ambiente completo, e a prática madura consiste em combinar fontes complementares e conciliar seus resultados em um repositório unificado. Cada fonte enxerga uma fatia diferente do ambiente e erra de forma diferente, o que torna a reconciliação entre elas um mecanismo de qualidade em si mesma. As fontes essenciais são as seguintes:

• CMDB: repositório de configuração mantido pelas equipes de infraestrutura, normalmente rico em donos e contratos de serviço, porém propenso a desatualização quando alimentado manualmente.
• Agente de EDR: fonte de maior frescor para endpoints, pois reporta sistema operacional, endereçamento, usuário logado e software instalado em intervalos curtos.
• MDM: cobertura primária para dispositivos móveis e para estações fora do domínio corporativo, incluindo cenários de trabalho híbrido.
• Varredura de rede: descobre ativos sem agente, incluindo equipamentos de rede, impressoras e dispositivos IoT, por meio de ferramentas de descoberta e varredura de portas.
• APIs de cloud: cada provedor expõe inventário por API, e o consumo dessas APIs é a única forma confiável de capturar workloads efêmeros e recursos criados fora do fluxo padrão.
• Active Directory e Entra ID: objetos de computador, contas de serviço e relações de confiança revelam ativos de forma barata e ampla, com histórico de último logon.
• DHCP e DNS: registros de concessão e resolução histórica ajudam a nomear ativos que apareceram em varreduras sem identificação.

# Computadores do Active Directory com sistema operacional e último logon
Get-ADComputer -Filter * -Properties OperatingSystem, LastLogonDate, IPv4Address |
  Select-Object Name, OperatingSystem, IPv4Address, LastLogonDate

// Filtro LDAP para localizar objetos de computador do tipo servidor no domínio
(&(objectCategory=computer)(operatingSystem=*Server*))

A cadência de cada fonte deve ser explícita e registrada, porque inventário sem cadência definida é inventário que se deteriora em silêncio. A tabela a seguir sugere cadências mínimas por fonte de coleta:

4. Atributos Essenciais de Cada Ativo

O valor do inventário está nos atributos que acompanham cada registro. Um hostname sem dono e sem criticidade não permite priorizar nada, é apenas um nome. A tabela a seguir consolida os atributos mínimos recomendados e o uso de cada um no programa de CTI e Threat Hunting.

A escala de criticidade deve ser simples e estável. Um padrão prático usa quatro níveis: crítico para serviços que sustentam receita ou dados sensíveis; alto para serviços essenciais de operação interna; médio para serviços de apoio; baixo para ativos isolados e de laboratório. O ponto decisivo é que a nota derive do impacto de negócio acordado com as áreas, e não da percepção da equipe de segurança, porque é essa nota que dita a ordem de patching, de contenção e de investigação.

5. Descoberta Contínua versus Inventário Estático

A escolha entre inventário estático e descoberta contínua define a confiabilidade de tudo que se apoia sobre ele. Inventários revisados trimestralmente acumulam ativos mortos e deixam de fora ativos novos, exatamente a janela que os adversários exploram. Um levantamento pontual tem meia-vida curta: em ambientes com provisionamento automatizado, a população de ativos muda de forma perceptível em semanas.

A meta operacional é a descoberta contínua com quatro mecanismos combinados. Varreduras de rede agendadas cobrem o que não tem agente; a sincronização diária com APIs de nuvem captura workloads efêmeros; os agentes reportam estado em tempo próximo ao real; e a comparação automática entre descoberta e inventário conhecido gera alerta para todo ativo novo, materializando a salvaguarda INS.1.3. O alerta de ativo novo não é ruído, é a unidade básica de governança: cada ocorrência precisa virar registro oficial ou constatação documentada de que o achado já estava coberto.

6. Qualidade do Inventário: Completude, Frescor e Divergência

A qualidade do inventário precisa ser medida com métricas explícitas e acompanhada como qualquer outro indicador do programa. Três métricas cobrem a maior parte do problema:

• Completude: percentual de ativos com todos os atributos obrigatórios preenchidos, incluindo dono e criticidade.
• Frescor: idade da última confirmação de cada ativo, com meta de dias para endpoints e de semanas para infraestrutura estável.
• Divergência: quantidade de ativos vistos por uma fonte e ausentes nas demais, que indica lacunas de cobertura ou registros duplicados.

// Hosts vistos pelo EDR nas últimas 24 horas, para reconciliação com o inventário oficial
DeviceInfo
| where Timestamp > ago(1d)
| summarize UltimaVista = max(Timestamp), Sistema = any(OSPlatform) by DeviceId, DeviceName
| project DeviceName, Sistema, UltimaVista

// Dispositivos observados na rede sem agente de segurança instalado
DeviceDiscoveryEvents
| where Timestamp > ago(7d)
| summarize UltimaObs = max(Timestamp) by RemoteDeviceName

O resultado dessas consultas deve ser comparado ao repositório unificado, e todo host que aparece em uma fonte sem registro oficial abre um item de triagem. A reconciliação agendada, executada diariamente, é o mecanismo prático que transforma descoberta em governança. Completude abaixo de 95% e frescor acima de 30 dias para endpoints são sinais de que o inventário precisa de intervenção antes de servir a qualquer processo de priorização.

7. Ciclo de Vida do Ativo e Histórico de Mudanças

A salvaguarda INS.1.4 exige monitorar mudanças no ciclo de vida dos ativos e manter histórico para auditoria e investigação forense. O ciclo de vida tem quatro eventos que precisam virar registro: provisionamento, mudança de estado, transferência de dono e descomissionamento. A ausência de histórico torna impossível responder, durante um incidente, se aquela porta aberta ou aquele software era legítimo antes da intrusão.

8. Salvaguardas do Controle por Nível

A ordem de implantação recomendada segue a numeração das salvaguardas. Primeiro se estabelece a descoberta interna e externa com cobertura mensurável; em seguida se automatiza a detecção de desvios, para que ativo novo e mudança de estado virem eventos; por último se conecta o inventário ao pipeline de CTI, de modo que a inteligência de ameaças enriqueça cada ativo com risco real. Pular etapas produz inventários visualmente completos, mas sem mecanismo de correção.

9. Relação com Threat Hunting e Resposta a Incidentes

Para o Threat Hunter, o inventário é o delimitador de escopo de toda hipótese. Uma caça orientada por exposição parte da pergunta sobre quais ativos críticos executam o software afetado por uma CVE com exploit público, e essa pergunta só é respondível se o inventário cobrir software e criticidade. Uma caça baseada em comportamento também depende do inventário para saber que classe de host está sob análise, porque o normal de um servidor web não é o normal de uma estação de projeto.

Na resposta a incidentes, o inventário encurta as primeiras horas, que são as mais decisivas. Saber imediatamente qual serviço depende do host comprometido, quem é o dono e qual a criticidade permite decidir entre isolamento total e contenção parcial em minutos. O histórico de mudanças do ativo alimenta ainda a forense ao responder se aquela porta aberta ou aquele software era legítimo antes do incidente, e a lista de ativos sem cobertura de segurança orienta a busca por vítimas não instrumentadas.

10. Erros Comuns e Pontos de Atenção

• Inventar apenas estações gerenciadas: limitar o inventário ao que tem agente ignora justamente os ativos que mais aparecem em incidentes, como câmeras, impressoras e laboratórios.
• Ignorar OT e IoT: ambientes industriais e dispositivos headless raramente aceitam agentes; exigi-los como condição de cobertura garante a perpetuidade do ponto cego.
• Tratar cloud como exceção: workloads efêmeros e contas de teste em nuvem costumam escapar do inventário corporativo, embora sejam alvo constante de varredura automatizada de adversários.
• Confiança cega na CMDB: bases alimentadas manualmente acumulam registros fantasma; a conciliação com fontes automáticas é obrigatória.
• Inventário sem dono: ativo sem dono definido não tem quem o corrija, e essa ausência vira gargalo em toda remediação.
• Descoberta sem governança: detectar ativo novo sem fluxo de triagem que transforme o alerta em registro oficial reduz a descoberta a ruído.
• Iniciar sem critérios de profundidade: inventariar tudo com o mesmo nível de detalhe esgota o esforço da equipe; a criticidade deve definir a granularidade da coleta.

11. Critérios de Sucesso e Métricas

• Completude de atributos obrigatórios acima de 95%, medida semanalmente sobre a base consolidada.
• Frescor mediano abaixo de 7 dias para endpoints e abaixo de 30 dias para infraestrutura de servidor.
• Divergência entre fontes tendendo a zero, com toda divergência aberta virando triagem em 48 horas.
• Percentual de ativos com agente de EDR acima de 95% nas categorias onde o agente é tecnicamente viável.
• Tempo médio para incorporar ativo novo ao inventário abaixo de 24 horas após a primeira observação.
• Percentual de ativos com dono de negócio e responsável técnico definidos, com meta de 100%.

O acompanhamento dessas métricas pertence ao grupo MET, e cada falha recorrente deve alimentar a melhoria do processo de coleta, e não a tolerância com o desvio. Inventário é o tipo de controle cuja deterioração é silenciosa, e por isso a medição precisa ser permanente, com dono próprio e revisão em cadência fixa.

12. Integração com Outros Controles do Framework CTH

O INS.1 alimenta diretamente o INS.2, que detalha o software executado em cada ativo inventariado, e o INS.3, que estende o inventário para a superfície exposta na Internet. O INS.5 depende do inventário para segmentar as baselines de normalidade por função e criticidade do ativo, e o INS.4 usa a lista de ativos para atribuir dono e prioridade a cada exposição detectada.

No plano das capacidades, o grupo DAT consome o inventário para dar contexto a alertas e enriquecer telemetria, o grupo MET usa completude e frescor como indicadores do programa, e a prática de CTI se beneficia do cruzamento entre campanhas de ameaça e ativos afetados exigido na salvaguarda INS.1.5. Na resposta, os controles do grupo IR assumem o histórico do ciclo de vida do ativo como insumo forense. O resultado prático dessa integração é que cada nova inteligência, cada alerta e cada hipótese de caça passa a ser avaliada contra o ambiente real, e não contra uma suposição de como a organização gostaria que ele fosse.