PRT.1 - Proteção de Endpoint (EDR-AV)

Nota do grupo PRT (Defesa em Profundidade) do Framework CTH, derivada do capítulo 7, seção 7.1 (PRT.1.1 a PRT.1.5), do PDF de referência.
Posiciona o endpoint como última linha de defesa automatizada e como fonte primária de telemetria para CTI e Threat Hunting.
Expande o controle com prática de mercado de EDR-AV, governança de exclusões, tuning de falsos positivos e integração com SIEM e SOAR.

1. Contexto e Posicionamento no Framework CTH

O grupo PRT implementa a defesa em profundidade, princípio de que nenhuma camada de proteção é infalível e de que camadas complementares reduzem a chance de um comprometimento completo. PRT.1 cobre a camada de endpoint, historicamente o alvo primário dos adversários, tanto como ponto de entrada por phishing e exploração quanto como plataforma para movimentação lateral, elevação de privilégio e exfiltração. Quando os controles de perímetro e de rede falham, o endpoint é o último ponto automatizado capaz de bloquear, detectar e responder à atividade maliciosa.

No programa integrado de CTI e Threat Hunting, o EDR exerce dois papéis que devem ser geridos como um único ativo. O primeiro papel é preventivo e detectivo, com bloqueio de execução maliciosa e geração de alertas para o SOC. O segundo papel é de sensor, alimentando hunts, correlações no SIEM e investigações do CSIRT com telemetria de processos, rede, arquivos, registro e memória. Tratar o EDR apenas como gerador de alertas desperdiça a maior parte do valor da plataforma.

2. Do Antivírus por Assinatura ao EDR Comportamental

O antivírus clássico comparava hashes e padrões de bytes de arquivos contra listas de assinaturas conhecidas. Esse modelo perdeu eficácia diante de malware polimórfico, empacotadores que geram binários únicos por vítima e técnicas fileless, em que o código roda apenas em memória sem tocar o disco. Um adversário com acesso a ferramentas legítimas de administração, como PowerShell, WMI e os binários de Living-off-the-Land, nem precisa de malware convencional para atingir seus objetivos.

O EDR moderno desloca a detecção do conteúdo estático para o comportamento observado ao longo do tempo. Em vez de perguntar se um arquivo é malicioso, o sensor avalia cadeias de eventos, como um processo do Office que gera um filho PowerShell, que escreve em chave de autorun e abre conexão externa. Esse modelo, apoiado por modelos de machine learning em nuvem e pelo mapeamento de comportamentos em técnicas do MITRE ATT&CK, detecta variantes inéditas que compartilham o mesmo padrão operacional. A assinatura não desaparece, mas passa a ser uma das camadas dentro de um motor que combina heurística, reputação de binários, integridade de processo e memória de intenções do adversário.

A comparação abaixo resume a mudança de modelo e ajuda a explicar a stakeholders por que a plataforma de endpoint deixou de ser um antivírus para se tornar um sensor investigativo.

Essa mudança explica também por que o EDR exige gestão ativa de políticas e não apenas instalação de agente. Políticas de prevenção mal calibradas geram bloqueios indevidos que movem a organização para o modo passivo, enquanto políticas excessivamente permissivas desperdiçam a capacidade de detecção. O equilíbrio é alcançado com governança de configuração, testes e telemetria de eficácia.

3. Capacidades Modernas de um EDR

Um EDR maduro de mercado oferece um conjunto de capacidades que vai muito além do scan antimalware. A tabela a seguir resume as principais capacidades e o papel de cada uma dentro do programa CTH.

Capacidades adicionais relevantes para maturidade avançada incluem a varredura de memória de processos em busca de shellcode e ferramentas de adversário, o suporte a indicadores personalizados e regras YARA (ver PRT.5) e o gerenciamento de vulnerabilidades integrado ao sensor. Muitas plataformas agregam ainda visibilidade de identidade e de configuração de nuvem, aproximando o EDR de um XDR completo. A escolha do produto deve considerar, antes de tudo, a qualidade da telemetria exportável e não apenas a taxa de bloqueio em testes de laboratório, pois é a telemetria que sustenta PRT.1.5 e as atividades de hunting.

O exemplo abaixo ilustra uma cadeia de ataque típica e como o sensor a interpreta como árvore de processos, que é exatamente o formato em que a telemetria é consultada durante um hunt ou uma investigação.

outlook.exe (PID 4212)
  \-- wscript.exe (PID 5390)  script anexo executado pelo usuario
       \-- powershell.exe (PID 7411)  -enc base64, download de payload
            \-- cmd.exe (PID 7622)  cria servico para persistencia
                 \-- rundll32.exe (PID 7830)  carrega DLL de C2 e beacons

Nenhuma das etapas isoladas é um arquivo malicioso assinado por hash conhecido. É a relação entre os processos, combinada com rede e modificação de registro, que caracteriza a atividade adversária e justifica o alerta comportamental. Esse raciocínio de cadeia orienta tanto a construção de políticas quanto a leitura da telemetria pelo analista.

4. Cobertura por Plataforma e Lacunas Típicas

A cobertura deve ser medida por plataforma, pois cada sistema operacional expõe capacidades e lacunas diferentes no sensor. A meta declarada em PRT.1.1 é 100% dos endpoints gerenciados, e a lacuna real costuma aparecer nas exceções silenciosas, como servidores legados, kernels antigos e dispositivos que não comportam agente.

A recomendação prática é manter um relatório de cobertura cruzando a fonte de verdade de ativos (DAT.2) com a lista de hosts que reportam ao console do EDR. Divergências que persistem por mais de 24 horas indicam agentes desinstalados, hosts desligados ou falhas de provisionamento de imagem. Para hosts que não comportam agente, documentar o controle compensatório de rede e registrar formalmente o risco residual no plano de tratamento do GOV.

5. Governança de Exclusões de Detecção e Tuning

As exclusões são o ponto mais explorado de qualquer plataforma de endpoint. Um caminho excluído com permissão de escrita para usuários comuns, como o diretório temporário de uma ferramenta de desenvolvimento, transforma-se em zona segura para droppers e ransomware. A regra de ouro é tratar exclusão como exceção de risco aceito formalmente, e não como ajuste operacional informal solicitado por chamado.

Um processo mínimo de governança deve conter os seguintes elementos.

• Solicitação formal com justificativa técnica, escopo restrito ao mínimo funcional e prazo de validade declarado.
• Análise de risco que verifique permissões do caminho ou processo excluído, quem pode escrever nele e qual comportamento deixa de ser observado.
• Aprovação separada entre quem solicita e quem aprova, com revisão de segurança obrigatória antes da aplicação.
• Registro central com proprietário, motivo, data e escopo, permitindo auditoria completa das exceções ativas.
• Revisão trimestral com expiração automática como padrão, removendo exclusões que perderam a razão de existir.

O tuning para reduzir falsos positivos segue a mesma disciplina de contenção de escopo. Prefira exclusões comportamentais no console, como supressão de uma política específica para um grupo restrito, em vez de excluir processos inteiros da telemetria; use os canais de falso positivo do próprio fornecedor para corrigir a raiz do problema. Cada exclusão aplicada deve ser medida comparando a taxa de alertas antes e depois, documentando o que se deixou de observar. Quando uma exclusão se tornar permanente de fato, ela deve ser reavaliada como decisão de arquitetura, com assinatura do dono do risco.

A tabela compara pedidos de exclusão comuns com alternativas que preservam a observabilidade do sensor, formato útil para orientar a análise de risco durante o processo de aprovação.

6. EDR como Fonte de Telemetria para Threat Hunting

Além dos alertas, o EDR mantém um histórico pesquisável de eventos que serve de base para a maioria dos hunts em endpoint. Hipóteses derivadas de CTI, como abuso de LOLBins, DLL hijacking, extração de credenciais ou uso de ferramenta remota, são traduzidas em consultas diretas sobre essa telemetria. A consulta abaixo exemplifica a busca por processos filhos suspeitos gerados por aplicações do Office, padrão associado a phishing com macro e exploração de documento.

// KQL sobre telemetria de EDR (padrao Microsoft Defender for Endpoint)
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("winword.exe","excel.exe","powerpnt.exe","outlook.exe")
| where FileName in~ ("powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","cmd.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

Esse mesmo padrão opera como hunt programado quando executado diariamente e como conteúdo de detecção quando convertido em regra de correlação no SIEM. O time de hunting devolve ao SOC novas regras, novos casos de teste e requisitos de telemetria que ainda não estão sendo coletados (TH.11, TH.12). A tabela traz candidatos recorrentes de hunt em telemetria de EDR e a técnica do MITRE ATT&CK associada a cada um.

A disciplina recomendada é documentar cada hunt com a hipótese, a consulta, o período analisado e o resultado, alimentando o inventário de dados do TH.1. Hunts sem resultado também são valiosos, pois comprovam cobertura e se tornam detecções automatizadas quando o custo da consulta é baixo.

7. Integração com SIEM e SOAR

A integração com o SIEM atende ao requisito de PRT.1.2 de encaminhar todos os alertas críticos ao repositório central. O formato recomendado é a coleta dos alertas via API do EDR, com exportação contínua de telemetria bruta quando o volume e o custo permitirem. No SIEM, os alertas ganham contexto de identidade, VPN, DHCP e CTI, viabilizando correlações como alerta de EDR em um host que autenticou de forma anômala nos minutos anteriores. A telemetria completa no SIEM sustenta também correlações de longo prazo que o console do EDR não foi desenhado para executar.

Com o SOAR, os playbooks típicos incluem o enriquecimento automático de todo alerta com hash, reputação de domínio e histórico do host, o isolamento automático de host para alertas de alta severidade com aprovação por exceção, a coleta de artefatos e a abertura de caso no sistema de incidentes. A automação de resposta reduz o tempo de contenção de horas para minutos, mas exige salvaguardas explícitas, como lista de hosts sensíveis, período inicial em modo observação e trilha de auditoria de cada ação executada (AUT.1, AUT.5). Um playbook inicial de contenção de endpoint pode ser estruturado nos seguintes passos.

1. Alerta de alta severidade recebido do EDR no SIEM e replicado ao SOAR por webhook ou conector.
2. Enriquecimento automático com reputação do hash e do domínio de destino, histórico do host nos últimos 30 dias e dados do usuário autenticado.
3. Classificação de confiança: alta confiança dispara contenção automática; confiança intermediária abre tarefa para analista com prazo definido.
4. Contenção por isolamento de host, exceto para servidores da lista de sensíveis, que exigem aprovação humana registrada.
5. Coleta de artefatos em execução remota, fechamento do caso e feedback para CTI sobre os indicadores observados.

8. Salvaguardas por Nível de Maturidade

O Framework CTH organiza as salvaguardas de PRT.1 em três níveis cumulativos. A tabela a seguir consolida os requisitos com critérios objetivos de verificação.

A verificação dos critérios deve ser automatizada sempre que possível, com relatórios mensais de cobertura, idade de agente e status de atualização. Métricas úteis incluem o tempo médio entre a geração do alerta no EDR e a visualização no SIEM, o percentual de hosts com telemetria habilitada e a taxa de falsos positivos por política de detecção.

9. Erros Comuns e Pontos de Atenção

O erro mais caro é confiar 100% no EDR como controle único. Produtos de endpoint falham contra ataques direcionados, ferramentas assinadas abusadas pelo adversário, execução em memória e atividade em hosts excluídos por erro de configuração. A defesa em profundidade existe justamente porque essa falha é esperada, e a rede, a nuvem e o SIEM precisam cobrir as brechas que sobram.

Erros operacionais frequentes merecem lista explícita para revisão interna.

• Agentes sem atualização ou desinstalados silenciosamente, descobertos apenas durante incidente; monitorar a saúde dos agentes como serviço de primeira linha.
• Exclusões genéricas copiadas de fóruns, como a exclusão de um diretório inteiro ou de processos de backup sem escopo, criando zonas seguras exploráveis.
• Modo apenas de detecção configurado indefinidamente, no qual o produto detecta mas ninguém responde.
• Console de gestão restrito à equipe de infraestrutura, sem integração com o SOC, gerando dois mundos desconectados.
• Ausência de testes periódicos de eficácia, como as simulações do SIM.x, que verificariam se as políticas de bloqueio estão ativas em todos os grupos.

Um ponto adicional é o ciclo de vida do próprio EDR, incluindo atualização de versão do sensor, compatibilidade com sistemas operacionais novos e acompanhamento de comunicados do fornecedor sobre vulnerabilidades no produto. O EDR opera com privilégio máximo no host e, quando comprometido, entrega o sistema ao adversário. Acompanhar o feed do fornecedor com a mesma disciplina aplicada ao patch de sistema operacional faz parte do controle.

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

PRT.1 alimenta e recebe dados de praticamente todo o Framework CTH. A telemetria de endpoint sustenta os dados do DAT.1 e do DAT.4, os alertas correlacionados no SIEM respondem às hipóteses de hunting de TH.x, e os artefatos coletados alimentam o ciclo de CTI de CTI.4 e CTI.5. Regras YARA personalizadas de PRT.5 são executadas nos mesmos hosts por meio de PRT.1.4, e a resposta a incidentes de IR.x depende do isolamento de host e da resposta remota descritos nesta nota.

Na direção oposta, o CTI dissemina IOCs e TTPs que se tornam indicadores personalizados no EDR e conteúdo de hunting, enquanto as simulações de SIM.x, em especial o teste de IOCs e IOAs do SIM.4, validam se as políticas de bloqueio e as detecções comportamentais estão realmente ativas. Métricas de eficácia de endpoint, como cobertura, tempo de contenção e taxa de detecção por técnica do MITRE ATT&CK, alimentam o MET.x e a avaliação de maturidade do GOV, fechando o ciclo entre proteção, inteligência e governança.