PRT.2 - Proteção de Rede e Detecção (NDR)

Nota do grupo PRT (Defesa em Profundidade) do Framework CTH, derivada do capítulo 7, seção 7.2 (PRT.2.1 a PRT.2.5), do PDF de referência.
A rede é a camada que enxerga o que não tem agente, incluídos dispositivos sem suporte a endpoint e técnicas que evadem o EDR.
A nota expande o controle com prática de mercado de NDR, coleta com Zeek e Suricata, detecção de beaconing e lateralidade, e integração com CTI, SIEM e hunting de rede (TH.12).

1. Contexto e Posicionamento no Framework CTH

A defesa em profundidade pressupõe que o adversário vai contornar alguma camada, e a detecção de rede é a camada que permanece observando quando o endpoint é burlado. PRT.2 combina três famílias de tecnologia: o sensor de análise de tráfego que produz logs estruturados de protocolos, o IDS por assinatura que alerta sobre padrões conhecidos e a plataforma de monitoramento de fluxo que caracteriza comportamento ao longo do tempo. Juntas, elas fornecem visibilidade agnóstica de sistema operacional, cobrindo desde estações de trabalho até IoT, impressoras e equipamentos de OT que nunca receberão um agente.

No programa integrado, PRT.2 cumpre dois papéis que se reforçam. Como controle de proteção, ele reduz o tempo de permanência do adversário ao detectar comunicação de comando e controle, varreduras internas e exfiltração. Como fonte de dados, ele alimenta o DAT.2 com logs de conexão, DNS, HTTP e TLS, sustenta os hunts do TH.12 e fornece o contexto de rede que transforma alertas isolados de endpoint em casos investigáveis. Um programa de CTI sem telemetria de rede fica cego para metade do ciclo de vida de um ataque.

2. Por que a Rede Vê o que o Endpoint Esconde

Muitas das técnicas mais eficazes contra endpoints são justamente as mais visíveis na rede. Malware fileless roda em memória sem deixar artefato no disco, e ferramentas de administração legítimas abusadas pelo adversário não disparam assinatura nenhuma, mas ambas precisam se comunicar para receber ordens, baixar payloads e exfiltrar dados. O tráfego é obrigatório; o artefato no endpoint é opcional.

A rede também revela o que o endpoint não sabe reportar. Um EDR só existe nos hosts gerenciados, enquanto a movimentação lateral atravessa servidores legados, appliances e dispositivos sem agente, deixando rastro em fluxos SMB, RDP, WinRM e LDAP visíveis aos sensores. Além disso, a análise de rede correlaciona múltiplas vítimas simultaneamente, percebendo que dez estações iniciaram conexões idênticas na mesma janela, padrão que cada EDR isolado enxerga apenas parcialmente.

Essa propriedade transforma a rede em contrapeso natural das lacunas de cobertura de PRT.1. Onde não há agente, há fluxo; onde o payload é cifrado, restam metadados, timing e volume. O desenho da capacidade de rede deve ser guiado por essa pergunta: se o endpoint falhar silenciosamente, o que a rede precisa enxergar para revelar o comprometimento.

3. Visibilidade East-West versus North-South e Pontos de Coleta

Tráfego north-south é aquele que entra e sai da organização, cruzando o perímetro com a Internet, e é onde a maioria dos programas começa. Tráfego east-west é a comunicação interna entre servidores, estações e segmentos, e é onde a movimentação lateral, a descoberta de rede e a propagação de ransomware acontecem. Um NDR que monitora apenas o egress enxerga o início e o fim da intrusão, mas nada do que ocorre no meio.

Os pontos de coleta clássicos devem ser planejados de acordo com o tráfego a observar.

• Egress de Internet e links de DMZ, via TAP ou SPAN, cobrindo toda a saída e entrada, conforme PRT.2.1.
• Núcleo de rede do datacenter, capturando o tráfego entre VLANs de servidores e as comunicações críticas east-west.
• Segmentos com dados sensíveis, como ambientes de pagamentos, diretórios ativos e bases de dados, priorizados em PRT.2.3.
• Ambientes em nuvem, com espelhamento de tráfego de VPC ou sensores virtuais, já que o fluxo não passa pelo datacenter físico.
• Pontos de interligação com filiais e com a rede corporativa de usuários, onde o tráfego de estações converge.

A escolha entre TAP e SPAN afeta diretamente a qualidade da detecção e merece decisão consciente por ponto de coleta, conforme a comparação abaixo.

A recomendação prática é usar TAP nos pontos críticos de egress e no núcleo do datacenter, reservando SPAN para pontos secundários e para provas de conceito. Independentemente da tecnologia, cada ponto de coleta exige engenharia de capacidade real, porque SPAN mal dimensionado descarta pacotes em picos e cria falsa sensação de cobertura. Taxa de descarte, utilização do sensor e integridade da coleta devem ser verificadas continuamente no SIEM, tratando um sensor silencioso como incidente de visibilidade e não como ausência de eventos.

4. Capacidades de Detecção de um NDR

As detecções comportamentais de rede cobrem padrões que assinaturas sozinhas não alcançam. A tabela resume as capacidades centrais esperadas de um NDR e o padrão prático que cada uma observa.

O valor dessas detecções cresce quando são comparadas contra baselines por tipo de host, e não contra um único perfil global, pois um servidor de arquivo legítimo trafega ordens de magnitude mais que uma estação de trabalho. O PRT.2.5 avança para análise de machine learning nesses padrões, reduzindo a fricção de limiares manuais, mas o princípio de baseline por função do host permanece o mesmo e já é executável no nível intermediário.

5. NDR com Zeek e Suricata versus Produto Comercial

A stack open-source de referência combina o Zeek, que produz logs estruturados ricos por protocolo, e o Suricata, que executa detecção por assinatura em tempo real com conjuntos como Emerging Threats. O Suricata complementa o Zeek com regras de assinatura que identificam exploits, ferramentas de adversário e padrões de C2 conhecidos, incluindo regras personalizadas derivadas de CTI. Os logs do Zeek, por sua vez, são a matéria-prima mais valiosa para hunting comportamental, conforme o resumo abaixo.

A decisão entre construir com Zeek e Suricata ou adquirir um NDR comercial envolve os critérios comparados abaixo.

A escolha raramente é binária no mercado real. Muitas organizações executam Suricata com regras ET nos pontos de borda, Zeek para logs de protocolo que alimentam o data lake e um NDR comercial nos segmentos east-west críticos onde a detecção comportamental automática justifica o custo. O que importa para o Framework CTH é que os dados fluam para o mesmo SIEM, com esquemas consistentes, para que correlações e hunts possam cruzar as fontes (DAT.4, DAT.5).

6. Enriquecimento com CTI e Integração com SIEM

A telemetria de rede só se torna detecção de alta qualidade quando combinada com inteligência. Reputação de IP e domínio, infraestrutura conhecida de campanhas, fingerprints TLS associados a famílias de malware e padrões de user agent de ferramentas de adversário são camadas de enriquecimento que elevam um fluxo banal a um alerta priorizado. O caminho recomendado é automatizado: a plataforma de CTI (CTI.5, CTI.8) publica indicadores em lista consumível, os sensores e o SIEM fazem o cruzamento em tempo real e o resultado vem anotado com fonte, confiança e validade do indicador.

A tabela abaixo organiza os tipos de enriquecimento de CTI mais úteis sobre telemetria de rede e o efeito prático de cada um na fila do SOC.

A consulta abaixo ilustra a caça a tunelamento DNS no SIEM a partir de logs de DNS, hipótese clássica de TH.12 que combina telemetria de rede com raciocínio comportamental.

// KQL ilustrativo sobre logs de DNS no SIEM
DnsEvents
| where TimeGenerated > ago(24h)
| extend sub = tostring(split(Name, ".")[0])
| where strlen(sub) > 30 and RecordType in ("TXT","A","AAAA")
| summarize qcount=count(), src=make_set(ClientIP) by Name
| where qcount > 50
| order by qcount desc

No plano das assinaturas, o mesmo raciocínio aparece em regras Suricata personalizadas derivadas de relatórios de CTI, como no exemplo abaixo que casa uma URI de painel de C2 e um user agent característico, com controle de frequência para reduzir ruído.

# Regra Suricata ilustrativa para beacon HTTP de C2
alert http $HOME_NET any -> $EXTERNAL_NET any ( \
  msg:"SUSP - beacon HTTP com URI de C2 conhecida"; \
  flow:established,to_server; \
  http.uri; content:"/gate.php"; depth:10; \
  http.user_agent; content:"Mozilla/4.0 (compatible"; \
  threshold:type both, track by_src, count 5, seconds 300; \
  classtype:trojan-activity; sid:1000042; rev:3;)

A correlação final acontece no SIEM, cruzando alertas de rede com eventos de endpoint e de identidade. Exemplos de valor imediato incluem conexão externa periódica em host com execução suspeita de processo, SMB anômalo originado de estação que autenticou fora do horário e varredura interna seguida de autenticação em massa no diretório. Cada correlação validada deve virar conteúdo permanente de detecção, e não análise única de incidente.

7. Limitações Técnicas do NDR

A cifração é a limitação dominante. Com a maioria do tráfego em HTTPS, o conteúdo de payloads está frequentemente inacessível a sensores passivos, e alternativas de inspeção com interceptação TLS têm custo político, técnico e de privacidade alto. A resposta prática é analisar o que a cifra não esconde: padrões de handshake como JA3 e JA4, SNI, tamanho e timing de pacotes, volume por direção e reputação do destino, camada em que a detecção comportamental mantém boa eficácia.

Volume e custo formam a segunda restrição estrutural. Coletar tudo, em todos os pontos, com retenção longa, multiplica rapidamente o investimento em sensores, armazenamento e licenciamento do SIEM. A disciplina do TH.1 de inventariar dados e priorizar pontos de coleta de maior valor evita tanto a escassez de cobertura quanto a ingestão sem propósito. O DNS cifrado via DoH e DoT, por sua vez, esconde consultas de sensores passivos, o que recomenda controlar resolvidores permitidos na rede e monitorar diretamente o tráfego para resolsores externos.

Por fim, o NDR não substitui o endpoint, e sim o complementa. Sem a cadeia de processos do EDR, a rede identifica que algo suspeito ocorreu, mas tem dificuldade em responder quem, como e com qual binário. As duas camadas devem ser projetadas juntas, com pontos de correlação explícitos no SIEM.

8. Salvaguardas por Nível de Maturidade

As salvaguardas de PRT.2 seguem a estrutura de três níveis cumulativos do Framework CTH, conforme a tabela abaixo.

A verificação periódica deve incluir teste de cobertura de coleta, por exemplo, gerando tráfego de teste conhecido em cada ponto de coleta e medindo se o sensor e o SIEM o recebem. Métricas úteis são a taxa de descarte de pacotes por sensor, o tempo médio de atraso entre o evento e a ingestão no SIEM e a proporção de alertas de rede que recebem triagem em menos de 15 minutos.

9. Erros Comuns e Pontos de Atenção

O erro mais comum é confundir presença de sensor com cobertura efetiva. Um SPAN configurado no switch errado, uma VLAN esquecida ou um sensor saturado geram silêncio estatístico que se parece com rede tranquila. A saúde da coleta precisa ser tratada como dado de segurança, com alerta para sensores que param de reportar e reconciliação periódica entre a topologia de rede e o mapa de sensores.

Outros erros recorrentes merecem atenção explícita.

• Monitorar apenas o perímetro, deixando a movimentação lateral invisível até o momento da exfiltração.
• Ativar conjuntos de regras inteiros em modo alerta sem tuning, produzindo ruído que ensina o SOC a ignorar a fonte.
• Nunca revisar regras e limiares, acumulando detecções que não refletem mais o ambiente atual.
• Tratar o NDR como caixa de conformidade, sem integrar alertas e logs ao SIEM nem ao processo de hunting.
• Ignorar os logs de TLS e DNS como fonte de hunts, usando o NDR apenas como gerador de alarmes de assinatura.
• Deixar o tráfego de nuvem fora do desenho, já que instâncias em VPC não atravessam o datacenter físico.

Um alerta final diz respeito ao ciclo de vida das regras personalizadas derivadas de CTI. Indicadores de infraestrutura envelhecem rápido, e regras que casam com IPs descartados geram falso positivo sistemático. O repositório de regras precisa de expiração automática e revisão por campanha, alinhado ao controle de gestão de indicadores da plataforma de CTI.

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

PRT.2 é o par de cobertura de PRT.1, e os dois devem ser revisados juntos em cada avaliação de maturidade: onde um não enxerga, o outro precisa enxergar. Os logs produzidos alimentam o DAT.2 e o DAT.4, os alertas sustentam o DET.x e o ciclo de triagem do IR.2, e a visibilidade de rede é pré-requisito para o hunting de rede do TH.12 e para os baselines do TH.2.

Na direção da inteligência, o CTI.4 consome eventos de rede como fonte técnica, o CTI.8 recebe infraestrutura atacante extraída desses eventos para disseminação, e o PRT.3 se beneficia dos mesmos indicadores de reputação aplicados à borda web. Nas simulações, o SIM.5 mede a cobertura de detecção por técnica e evidencia técnicas visíveis apenas na rede, orientando o ajuste fino dos sensores. O fechamento do ciclo acontece nas métricas do MET.x, com tempo de detecção de lateralidade e taxa de correlação rede-endpoint como indicadores de maturidade.