O que significa “segurança de rede e monitoramento” na prática
Segurança de rede e monitoramento é o conjunto de práticas para reduzir a superfície de ataque na conectividade (rede interna, Wi-Fi, links com terceiros, nuvem, VPN, acesso remoto) e, ao mesmo tempo, observar continuamente o que acontece para detectar comportamentos anômalos e responder com rapidez. Na prática, isso se traduz em duas frentes que precisam andar juntas: (1) controles preventivos na rede (segmentação, filtragem, inspeção, roteamento seguro, proteção de DNS, controle de tráfego) e (2) capacidade de detecção e resposta (telemetria, logs, correlação, alertas, triagem, contenção e recuperação).
O ponto central deste capítulo é: monitorar “tudo” não é viável nem útil. O que funciona é definir critérios objetivos de detecção (o que é suspeito, o que é crítico, o que exige ação imediata), instrumentar a rede para coletar sinais relevantes e estabelecer um fluxo de resposta que seja executável com os recursos disponíveis.
Componentes típicos de uma arquitetura de segurança de rede
Segmentação e zonas
Segmentação é separar a rede em zonas com níveis de confiança diferentes e controlar o tráfego entre elas. Exemplos de zonas comuns: usuários (workstations), servidores, DMZ (serviços expostos), rede de gestão (management), rede de backups, rede de IoT/impressoras, ambientes de desenvolvimento/homologação e produção. O objetivo é reduzir movimento lateral: mesmo que um dispositivo seja comprometido, o atacante encontra barreiras e trilhas de auditoria ao tentar alcançar ativos mais sensíveis.
Controles de borda e de tráfego
Na borda (internet) e nos pontos de interconexão (filiais, nuvem, parceiros), normalmente entram: firewall com políticas explícitas, IDS/IPS (detecção/prevenção de intrusão), WAF para aplicações web, proteção de e-mail (gateway) e proteção de DNS. Internamente, podem existir firewalls de segmentação, NAC (controle de acesso à rede), proxies/secure web gateway e inspeção TLS quando aplicável e autorizado.
Telemetria e observabilidade
Monitoramento efetivo depende de fontes de dados. Em rede, as principais são: logs de firewall, logs de proxy/DNS, eventos de IDS/IPS, registros de VPN, logs de balanceadores, logs de roteadores/switches (mudanças e falhas), NetFlow/sFlow/IPFIX (metadados de tráfego), e, quando possível, captura de pacotes (PCAP) em pontos estratégicos para investigação. Esses dados alimentam um SIEM (ou plataforma de logs) e, idealmente, um NDR (Network Detection and Response) ou mecanismo de análise comportamental.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Critérios de detecção: como transformar “sinais” em alertas úteis
Critérios de detecção são regras e condições que definem quando um evento merece atenção. Eles devem ser objetivos, mensuráveis e alinhados ao risco operacional. Um bom critério responde: “o que observar”, “qual limiar”, “qual janela de tempo”, “qual contexto” e “qual ação esperada”.
Tipos de detecção (e quando usar cada um)
- Assinatura/IOC: detecta padrões conhecidos (hash, IP malicioso, domínio suspeito, regra de IDS). Útil para ameaças já catalogadas, mas pode falhar contra ataques novos.
- Comportamental/anomalia: detecta desvios de baseline (ex.: volume de DNS incomum, picos de tráfego para fora do horário). Útil para “unknown unknowns”, mas exige ajuste para reduzir falsos positivos.
- Baseada em política: detecta violações de regra (ex.: tráfego proibido entre zonas, uso de protocolos legados, acesso administrativo fora do jump server). É direta e costuma gerar alertas mais acionáveis.
- Detecção por sequência (cadeia): correlaciona eventos em etapas (ex.: varredura + tentativa de login + exfiltração). Reduz ruído e aumenta a confiança do alerta.
Critérios práticos que costumam gerar alto valor
A seguir, exemplos de critérios que, em muitas organizações, entregam boa relação sinal/ruído. Ajuste conforme seu ambiente e maturidade.
- Comunicação com destinos raros ou recém-observados: host interno iniciando conexões para domínios nunca vistos antes, especialmente em categorias de risco (recém-registrados, baixa reputação).
- DNS suspeito: alto volume de consultas NXDOMAIN, consultas para domínios com entropia alta (possível DGA), picos de TXT (possível exfiltração), ou uso de DoH/DoT não autorizado.
- Varredura e enumeração: um host tentando muitas portas em muitos destinos (scan horizontal) ou muitas portas em um destino (scan vertical) em curto período.
- Movimento lateral: aumento repentino de conexões SMB/RDP/WinRM/SSH entre estações, ou estação acessando muitos servidores em sequência.
- Autenticação e VPN: múltiplas falhas de login seguidas de sucesso, logins de VPN fora do padrão geográfico/horário, ou criação de túneis incomuns.
- Tráfego de saída anômalo: upload elevado para destinos externos, especialmente de servidores que normalmente não enviam grandes volumes.
- Uso de protocolos inseguros: detecção de Telnet, FTP sem TLS, SMBv1, SNMPv1/v2c, ou TLS fraco em segmentos onde não deveria existir.
- Alterações em dispositivos de rede: mudança de configuração fora de janela, alteração de ACL, criação de NAT/port-forward inesperado, ou login administrativo de origem não autorizada.
Como definir severidade com critérios objetivos
Severidade não deve ser “sensação”. Um modelo simples e prático combina impacto e confiança:
- Impacto (I): qual o potencial de dano se for real? Ex.: envolve dados sensíveis, produção, identidade privilegiada, exposição externa.
- Confiança (C): quão provável é ser incidente? Ex.: múltiplas fontes corroborando, IOC conhecido, sequência completa de ataque.
Uma regra operacional: Alta severidade quando (I alto) e (C média/alta). Média quando (I médio) e (C média), ou (I alto) e (C baixa). Baixa quando (I baixo) ou (C baixa) sem sinais adicionais.
Passo a passo: desenhando o monitoramento de rede com foco em detecção e resposta
1) Mapear pontos de coleta (onde a rede “fala”)
Liste os pontos onde você consegue coletar telemetria com menor esforço e maior cobertura:
- Firewalls de borda e de segmentação (logs de allow/deny, NAT, ameaças).
- DNS resolvers corporativos (consultas e respostas).
- Proxy/SWG (URLs, categorias, uploads/downloads).
- VPN concentrators (conexões, origem, duração, bytes).
- IDS/IPS (alertas e assinaturas acionadas).
- NetFlow/sFlow nos core switches/roteadores (metadados de tráfego).
- Ambientes em nuvem: logs de VPC/VNet flow, gateways, load balancers.
Critério prático: comece por firewall + DNS + VPN. Só depois expanda para NetFlow e PCAP conforme necessidade.
2) Definir o “mínimo viável” de logs e retenção
Sem retenção adequada, você detecta tarde e investiga mal. Defina um mínimo viável:
- Logs quentes (rápida busca): 30 dias para investigação operacional.
- Logs frios (armazenamento barato): 90 a 180 dias para retrocaça (threat hunting) e auditorias.
Se o volume for alto, priorize campos essenciais (timestamp, src/dst IP, src/dst port, usuário quando houver, ação allow/deny, regra/política, bytes, domínio/URL, device). Evite coletar “debug” contínuo sem propósito.
3) Normalizar e correlacionar (para não virar um “lixão de logs”)
Padronize nomes de campos e identidades: IP precisa ser associado a hostname, dono do dispositivo, localização, zona de rede e, quando possível, usuário. Sem contexto, o alerta vira “IP 10.0.3.15 fez algo” e ninguém consegue agir.
Na prática, isso significa integrar fontes de inventário/CMDB, DHCP, DNS interno e diretórios de usuários ao seu mecanismo de logs/SIEM para enriquecer eventos.
4) Criar um catálogo de casos de uso (use cases) priorizados
Em vez de habilitar centenas de regras, crie um catálogo de 10 a 20 casos de uso iniciais, com dono e métrica de qualidade (taxa de falso positivo, tempo de triagem). Exemplo de estrutura:
- Nome do caso de uso
- Objetivo (ameaça/risco que cobre)
- Fontes de dados
- Lógica do alerta (limiares e janela)
- Severidade
- Playbook de resposta
- Evidências esperadas
Comece pelos casos de uso que combinam: alta probabilidade, alto impacto e dados disponíveis.
5) Definir limiares e janelas com base em baseline
Para evitar alertas inúteis, estabeleça baseline: o que é normal por segmento e por tipo de ativo. Exemplo: um servidor de banco de dados pode ter tráfego alto interno, mas não deveria fazer conexões frequentes para a internet. Uma estação de trabalho pode acessar muitos domínios, mas não deveria abrir conexões SMB para dezenas de hosts.
Uma abordagem simples: rode as regras em “modo silencioso” por 1 a 2 semanas, colete estatísticas e ajuste limiares antes de notificar o time.
6) Preparar resposta: quem faz o quê quando o alerta dispara
Detecção sem resposta vira “painel bonito”. Para cada alerta relevante, defina ações mínimas:
- Triagem: confirmar se é falso positivo, coletar contexto, classificar severidade.
- Contenção: bloquear IP/domínio, isolar host, desabilitar conta, derrubar sessão VPN, aplicar regra temporária.
- Erradicação: remover persistência, corrigir configuração, fechar porta, ajustar segmentação.
- Recuperação: restaurar serviço, reabrir acesso com segurança, monitorar recorrência.
Mesmo que sua equipe seja pequena, deixe claro quais ações são permitidas sem aprovação (por exemplo, bloquear domínio malicioso por 24h) e quais exigem validação (por exemplo, bloquear um serviço crítico).
Playbooks de resposta (exemplos práticos)
Playbook 1: Suspeita de exfiltração de dados via tráfego de saída
Gatilho (detecção): servidor interno com upload acima do baseline para destino externo novo, por mais de X minutos, fora de janela esperada.
Passo a passo:
- Identificar o ativo: hostname, função, dono, zona de rede.
- Verificar destino: reputação do domínio/IP, ASN, geolocalização, histórico de conexões.
- Checar contexto: houve mudança recente (deploy, backup externo, integração)?
- Correlacionar com DNS/proxy: quais domínios foram resolvidos e acessados.
- Se suspeita alta: aplicar contenção temporária (bloqueio do destino no firewall/proxy) e/ou limitar egress do host.
- Coletar evidências: fluxos (NetFlow), logs de firewall, amostra de PCAP se disponível, horários e volumes.
- Abrir incidente e acionar responsável do sistema para validar tráfego legítimo.
Playbook 2: Varredura interna e possível movimento lateral
Gatilho (detecção): um host inicia conexões para muitas portas/destinos internos em janela curta, seguido de tentativas de autenticação.
Passo a passo:
- Confirmar se o host é ferramenta legítima (scanner autorizado, monitoramento, inventário).
- Se não for: identificar usuário associado (DHCP/NAC/AD) e localização.
- Verificar se há conexões para protocolos de administração (RDP/SSH/WinRM/SMB).
- Contenção: isolar o host na rede (NAC/quarentena) ou bloquear tráfego leste-oeste temporariamente.
- Buscar outros sinais: alertas de IDS, conexões para destinos externos, picos de DNS.
- Registrar lista de alvos acessados para checar comprometimento secundário.
Playbook 3: Alteração suspeita em firewall/roteador/switch
Gatilho (detecção): mudança de configuração fora de janela, criação de regra permissiva, novo NAT para serviço interno, ou login admin de origem não autorizada.
Passo a passo:
- Validar origem do acesso administrativo (IP, usuário, método, MFA quando aplicável).
- Comparar configuração atual vs. última versão aprovada (diff).
- Se não autorizado: reverter mudança para baseline, revogar credenciais usadas e revisar contas administrativas.
- Checar logs de tráfego: houve exploração do novo caminho (port-forward) ou aumento de tentativas externas?
- Preservar evidências: exportar logs e configuração, registrar horários e comandos.
Como reduzir falsos positivos sem perder cobertura
Enriquecimento e listas de exceção controladas
Boa parte do ruído vem de falta de contexto. Enriquecer com “quem é o ativo” e “qual é a função” reduz alertas desnecessários. Quando precisar de exceções (por exemplo, um servidor que acessa um serviço externo específico), registre como exceção controlada: qual destino, por quê, por quanto tempo e quem aprovou. Exceção não deve virar “liberou geral”.
Alertas por agregação e não por evento único
Um único deny no firewall pode ser normal. Cem denies para portas diferentes em 2 minutos é outra história. Prefira alertas agregados com limiar e janela temporal.
Severidade dinâmica
O mesmo evento pode ter severidade diferente dependendo do ativo e da zona. Exemplo: conexão de saída para domínio recém-registrado pode ser média em uma estação de usuário, mas alta em um servidor de produção que não deveria navegar.
Monitoramento de rede em ambientes híbridos e nuvem
Em nuvem, parte do “perímetro” muda: você pode não ter appliances tradicionais, mas tem logs nativos e controles distribuídos. Práticas úteis:
- Ativar e centralizar flow logs de redes virtuais (VPC/VNet) e logs de gateways/balanceadores.
- Monitorar mudanças de regras de security groups/NSGs e rotas (principalmente abertura para 0.0.0.0/0).
- Detectar exposição acidental: serviços internos publicados, portas administrativas abertas, endpoints sem restrição de origem.
- Correlacionar identidade e rede: quem criou a regra, de onde, em qual horário, com qual justificativa.
Métricas operacionais para saber se o monitoramento está funcionando
Sem métricas, você não sabe se está detectando melhor ou só gerando mais alertas. Métricas práticas:
- MTTD (Mean Time To Detect): tempo médio entre início do evento e detecção.
- MTTR (Mean Time To Respond): tempo médio entre detecção e contenção.
- Taxa de falso positivo por caso de uso: % de alertas fechados como benignos.
- Cobertura de telemetria: % de segmentos/links críticos com logs chegando corretamente.
- Qualidade de logs: % de eventos com campos essenciais preenchidos (src/dst, usuário, ação, regra).
- Incidentes recorrentes: quantos alertas repetem a mesma causa raiz (indicador de falta de correção).
Checklist prático de implementação (primeiros 30 dias)
Semana 1: visibilidade mínima
- Centralizar logs de firewall, DNS e VPN em um repositório pesquisável.
- Garantir sincronização de horário (NTP) em dispositivos de rede.
- Definir retenção mínima e validar volume/custo.
Semana 2: primeiros casos de uso
- Implementar 5 a 8 alertas agregados (DNS suspeito, egress anômalo, varredura, VPN fora do padrão, mudança em firewall).
- Rodar em modo silencioso para baseline e ajuste de limiares.
Semana 3: playbooks e contenção
- Escrever playbooks curtos (1 página) para os alertas principais.
- Definir ações de contenção permitidas e como registrar evidências.
- Testar um exercício: simular alerta e executar triagem e bloqueio temporário.
Semana 4: melhoria de qualidade
- Enriquecer eventos com contexto (hostname, dono, zona, criticidade do serviço).
- Revisar falsos positivos e criar exceções controladas com prazo.
- Adicionar uma fonte extra de alto valor (NetFlow ou IDS/IPS) se fizer sentido.
Exemplos de regras (pseudo-lógica) para critérios de detecção
# 1) Possível DGA / DNS anômalo (entropia alta + NXDOMAIN alto) em 10 minutos
IF dns.nxdomain_count_by_host > 50 IN 10m AND dns.avg_query_entropy_by_host > 3.8 THEN alert("DNS suspeito", severity="medium")
# 2) Varredura interna (muitos destinos/portas) em 5 minutos
IF flow.unique_dst_ips_by_src > 30 IN 5m AND flow.unique_dst_ports_by_src > 20 IN 5m THEN alert("Possível scan", severity="medium")
# 3) Egress anômalo de servidor (upload alto para destino novo)
IF asset.type == "server" AND flow.bytes_out > baseline(asset).p95_bytes_out*3 IN 15m AND flow.dst_is_new == true THEN alert("Possível exfiltração", severity="high")
# 4) Mudança em firewall fora de janela
IF device == "firewall" AND event.type == "config_change" AND time NOT IN approved_change_window THEN alert("Mudança não planejada", severity="high")
