INS.2 - Inventário de Software e Aplicações

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 aprofunda o inventário de ativos na camada de software, onde se concentram vulnerabilidades exploráveis e abusos de ferramenta legítima.
Papel no programa: conhecer o software que executa em cada ativo, distinguir o autorizado do não autorizado e correlacionar versões com ameaças ativas para priorizar correção e caça.

1. Contexto e Posicionamento no Framework CTH

O INS.2 aprofunda o INS.1 em uma dimensão que concentra boa parte do risco operacional: o software. Aplicações não gerenciadas representam risco significativo porque podem conter vulnerabilidades conhecidas sem correção, podem violar políticas de segurança, como a transmissão de dados para servidores externos, e expandem a superfície de ataque de formas que a equipe de segurança desconhece. Se o inventário de ativos diz o que existe, o inventário de software diz o que roda, e é sobre essa camada que a gestão de vulnerabilidades e boa parte das hipóteses de Threat Hunting se apoiam.

O controle materializa, na prática de mercado, o segundo controle do CIS Controls v8, dedicado a software suportado e autorizado. A lógica é a mesma do INS.1 elevada à granularidade de aplicação: cada binário instalado é uma decisão de risco, e a organização precisa enxergar essas decisões para governá-las. Dentro do Framework CTH, o INS.2 alimenta o INS.4 com exposições concretas, sustenta a priorização de remediação por CTI e fornece aos Threat Hunters o repertório de aplicações que delimita caças orientadas a vulnerabilidade e a abuso de ferramenta legítima.

2. Software Autorizado e Não Autorizado

A distinção central do controle é binária e precisa ser operacionalizada por política formal. Software autorizado é aquele aprovado para uma categoria de ativo, com fornecedor homologado, versão mínima aceitável e canal de distribuição definido. Software não autorizado é todo o restante, e convém separá-lo em três subcategorias com tratamento distinto: software proibido por política, como compartilhadores de arquivo e criptomineradores; software tolerado mas não homologado, como utilitários instalados por usuários para produtividade; e software legítimo porém vulnerável, que é autorizado em função, mas inaceitável na versão em execução.

A lista autorizada (allowlist) deve ser mantida por categoria de ativo, porque o que é legítimo em uma classe de host é suspeito em outra. Ferramentas de acesso remoto são o exemplo clássico: em estações de suporte, uma ferramenta de atendimento remoto pode ser aprovada; em servidores de produção ou em estações do financeiro, a mesma ferramenta é um forte sinal de acesso paralelo ou de preparação de persistência.

A lista precisa de governança viva para não morrer por excesso de exceção. Cada pedido de exceção deve registrar justificativa, prazo de validade e revisão obrigatória, e exceções vencidas devem virar evento de conformidade. Quando o volume de exceções passa de uma pequena fração do catálogo, o problema está no processo de aprovação, e não na lista.

3. Fontes de Inventário de Software

A coleta de software deve combinar fontes com granularidades diferentes, porque cada uma cobre um cenário que as outras não alcançam. O agente de segurança do endpoint é a fonte primária, coletando nome do software, versão, fornecedor, data de instalação e caminho de instalação de forma centralizada e atualizada em intervalo máximo de 24 horas, conforme a salvaguarda INS.2.1. O MDM cumpre papel equivalente no parque móvel, e a ferramenta de consulta ad-hoc de endpoints permite investigar estados de configuração pontuais sem aguardar o ciclo de coleta.

Registros do sistema operacional e do instalador complementam o quadro com histórico temporal. No Windows, as chaves de desinstalação fornecem o inventário instalado, e o log do MsiInstaller registra cada instalação e desinstalação com data, permitindo reconstruir quando um software apareceu e quem executou o instalador:

# Inventário instalado a partir das chaves de desinstalação
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" |
  Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
  Where-Object { $_.DisplayName }

Pacotes gerenciados por repositórios corporativos, gerenciadores de pacotes Linux e imagens de container devem ser conciliados com a coleta do agente, pois software instalado fora do canal oficial é, por definição, suspeito. Em ambientes de nuvem, o inventário de imagens e as receitas de infraestrutura como código precisam entrar no mesmo repositório, porque um container efêmero com pacote vulnerável é tão explorável quanto um servidor físico.

No parque Linux, a coleta combina os gerenciadores de pacote nativos com a telemetria do agente, porque binários instalados fora do gerenciador são exatamente os que escapam do canal oficial. O cruzamento entre as duas fontes, comparando o que o gerenciador conhece com o que o agente observa em execução, revela ferramentas operadas diretamente de diretórios de usuário:

# Inventário de pacotes em Linux, por gerenciador
dpkg -l 2>/dev/null | awk '/^ii/{print $2, $3}'
rpm -qa --qf '%{NAME} %{VERSION}\n' 2>/dev/null

4. Controle de Versões e Correlação com Vulnerabilidades

Capturar apenas o nome do software é insuficiente; a versão é o atributo que conecta inventário a risco. A correlação automática entre o inventário e bases de vulnerabilidades, como NVD e CVE, identifica software com falhas críticas ou de alta severidade instaladas nos ativos, gerando alertas priorizados por severidade e por exposição do ativo. Esse é o núcleo da salvaguarda INS.2.3 e a ponte formal entre o INS.2 e a gestão de vulnerabilidades.

A priorização puramente por severidade genérica gera filas impraticáveis. O diferencial do Framework CTH é inserir CTI de vulnerabilidade nesse cálculo: uma falha com exploit público e exploração ativa em campanhas do setor salta para o topo da fila, enquanto uma falha crítica sem exploit conhecido e em ativo não exposto espera o ciclo normal de patching. A consulta a seguir exemplifica o cruzamento entre inventário e hipótese de abuso, com utilitários de acesso remoto:

// Utilitários de acesso remoto presentes no parque, com versão instalada
DeviceTvmSoftwareInventory
| where SoftwareName =~ "anydesk"
    or SoftwareName has "rustdesk"
    or SoftwareName has "teamviewer"
| project DeviceName, SoftwareName, SoftwareVersion

A mesma lógica vale na direção inversa: quando a CTI identifica que um software presente no inventário passou a ser usado como vetor de ataque em campanhas direcionadas ao setor, o controle deve gerar alerta prioritário para patching ou remediação, mesmo que a versão instalada ainda não tenha CVE atribuída. Essa capacidade de reagir à inteligência antes do boletim formal é o que separa um inventário reativo de um inventário operado como fonte de inteligência.

5. Imagens Douradas e Repositórios Controlados

Imagens douradas (golden images) são o mecanismo mais econômico de impor o estado inicial de software autorizado. Uma imagem contém o sistema operacional, as atualizações correntes, os agentes de segurança e o conjunto aprovado de aplicações; tudo que não está na imagem precisa chegar por canal controlado. O risco recorrente é a imagem envelhecer: uma imagem sem manutenção de seis meses implanta dezenas de vulnerabilidades conhecidas em cada máquina nova criada. O pipeline de imagens precisa de manutenção contínua, com reconstrução automatizada ao menos mensal e verificação de conformidade como critério de aceite.

Repositórios controlados completam o modelo em Linux e containers, e catálogos de autoatendimento cumprem o mesmo papel em estações Windows. A regra de ouro é simples: oferecer um caminho oficial e conveniente para obter software é mais eficaz do que tentar bloquear todos os caminhos alternativos. Quando o catálogo oficial demora semanas para aprovar um utilitário legítimo, o usuário instala por conta própria, e a organização perde exatamente a visibilidade que o controle existe para garantir. Uma imagem dourada saudável atende a cinco critérios:

• Atualização automatizada, com reconstrução da imagem ao menos mensal e teste em ambiente isolado antes da publicação.
• Agentes de segurança e de coleta embutidos, garantindo que toda máquina derivada da imagem nasça instrumentada.
• Versões de software documentadas e conciliadas com a allowlist vigente, sem software órfão herdado de versões anteriores.
• Publicação por canal único, com bloqueio administrativo de instalação manual em imagens de produção.
• Auditoria comparativa entre imagem publicada e software observado nos hosts implantados, para detectar derivação não autorizada.

6. Detecção de Software Não Autorizado como Fonte de Hipóteses de Hunting

Instalações atípicas são um dos gatilhos mais férteis de hipóteses de caça. A salvaguarda INS.2.4 exige monitoramento de instalações não autorizadas em tempo próximo ao real, com evento de segurança para cada instalação fora da allowlist. Do ponto de vista de hunting, cada instalação responde perguntas que vão além da conformidade: quem executou o instalador, de onde o binário veio, se o processo pai é coerente com um fluxo de instalação corporativa e se o software começou a se comunicar imediatamente após a instalação.

Utilitários de acesso remoto merecem hipótese dedicada, porque dão acesso interativo ao adversário sem explorar vulnerabilidade alguma. A presença dessas ferramentas em hosts sem permissão formal sugere suporte paralelo, persistência pós-exploração ou operação com credenciais válidas, e a regra a seguir exemplifica a detecção da instalação:

title: Instalacao de utilitario de acesso remoto via MsiInstaller
logsource:
  product: windows
  service: application
detection:
  selecao_msi:
    Provider_Name: MsiInstaller
    EventID: 1033
    Data|contains:
      - "AnyDesk"
      - "RustDesk"
      - "TeamViewer"
  condition: selecao_msi

A telemetria de endpoint permite detectar a instalação nova no momento em que ela se registra no sistema, e não apenas na próxima sincronização diária de inventário. O cruzamento do evento de registro com o processo que o gerou responde, em um único passo, o que foi instalado e quem instalou:

// Novas entradas de software registradas nas últimas 24 horas
DeviceRegistryEvents
| where Timestamp > ago(1d)
| where ActionType == "RegistryValueSet"
| where RegistryKey has @"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall"
| project Timestamp, DeviceName, RegistryKey, InitiatingProcessFileName

O inventário de software também alimenta hipóteses de caça de forma recorrente. Padrões que merecem investigação dedicada incluem:

• Ferramenta de acesso remoto instalada em host sem permissão formal, com sessão externa iniciada nas 24 horas seguintes.
• Instalação de software a partir de diretório temporário ou de compartilhamento de rede, fora do catálogo corporativo.
• Utilitário de tunelamento ou proxy presente em servidor que nunca teve justificativa funcional para esse tipo de conexão.
• Instalação do mesmo software em dezenas de hosts em curto período, padrão de implantação automatizada ou de propagação por credenciais válidas.
• Software de criptomineração ou processo com consumo anômalo de CPU em janela noturna, associado a hosts recém-inventariados com binário desconhecido.

7. Salvaguardas do Controle por Nível

A implantação começa pela cobertura de coleta, porque allowlist sem inventário confiável é documento sem execução. Na sequência, a allowlist por categoria transforma a coleta em comparação automática, e as salvaguardas intermediárias conectam o inventário ao risco. A salvaguarda avançada fecha o ciclo ao tornar o inventário sensível a campanhas de ameaça, permitindo que a organização responda a exploração ativa antes que o alerta externo chegue.

8. Erros Comuns e Pontos de Atenção

• Coletar nome sem versão: inventário sem versão impede correlação com CVE e reduz o controle a contagem de software, sem valor de risco.
• Allowlist genérica: uma única lista para toda a organização gera exceções em massa, e exceção em massa equivale a não ter lista.
• Ignorar software portátil: executáveis que não se registram nas chaves de desinstalação, como ferramentas executadas de diretórios de usuário, exigem telemetria de processo para serem vistos.
• Cobertura restrita ao parque Windows: deixar de coletar Linux, containers e macOS oculta boa parte da infraestrutura de serviço moderna e dos alvos preferenciais de campanhas atuais.
• Tratar alerta de instalação como fim do fluxo: instalação não autorizada precisa de triagem com dono, prazo e decisão registrada, e não apenas de notificação silenciosa.
• Descolar inventário de patching: inventar software sem conectar o resultado ao processo de correção produz visibilidade sem ação.
• Depender apenas do agente: ambientes onde o agente pode ser desinstalado precisam de contraprova por varredura de rede e consulta ad-hoc de endpoints.

9. Critérios de Sucesso e Métricas

• Cobertura de coleta de software acima de 95% dos endpoints gerenciados, medida por amostragem mensal.
• Percentual de software fora da allowlist abaixo de 5% do parque, com tendência decrescente trimestral.
• Tempo médio entre instalação não autorizada e decisão de triagem abaixo de 24 horas.
• Tempo médio de correção de software com CVE crítica e exploração ativa abaixo de 7 dias.
• Idade máxima da imagem dourada abaixo de 60 dias, com reconstrução automatizada documentada.
• Zero exceções de allowlist vencidas sem decisão registrada na revisão mensal.

O acompanhamento dessas métricas pertence ao grupo MET, e cada meta precisa de dono formal no grupo GOV. Métricas de inventário de software só são úteis quando reagem: uma allowlist com 30% de exceções vigentes não é apenas um indicador ruim, é um diagnóstico de processo que precisa ser tratado como tal.

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

O INS.2 é consumido transversalmente pelo programa. Na dimensão de exposição, cada software vulnerável em ativo exposto é um IOE que alimenta o INS.4, e a combinação com ameaça ativa definirá a prioridade máxima de remediação. Na dimensão de hunting, o inventário delimita caças orientadas a vulnerabilidade e fornece o repertório de software para hipóteses de abuso de ferramenta legítima, conectando-se ao grupo HNT. Na dimensão de coleta, o grupo DAT consome o inventário para dar contexto às telemetrias de processo e de rede.

A gestão de vulnerabilidades é o integrador operacional mais direto: o ciclo de inventário, correlação com CVE, enriquecimento com CTI e acionamento de patching deve ser um pipeline automatizado, com métricas de tempo de correção por criticidade acompanhadas no grupo MET. Em políticas, o controle se liga ao grupo GOV, que mantém a allowlist formal e as exceções aprovadas, garantindo que a técnica reflita uma decisão de governança. Em resposta, o grupo IR usa o inventário de software do ativo comprometido para reconstruir o vetor de entrada e buscar outros hosts com o mesmo binário instalado.