Logging & detection - sinais e alertas

Logging & detection é a peça da detecção que vive de sinal: trilhas de auditoria, logs de plano de controle, logs de plano de dados, eventos de runtime, saídas de DNS e eventos de identidade. O trabalho é coletar tudo isso em um só lugar, reter por tempo suficiente e disparar alerta quando aparece algo fora do padrão.

CSPM vasculha configuração; CWPP vasculha comportamento de workload. Aqui a pergunta é mais ampla: 'o que aconteceu nesta conta nos últimos 90 dias, e aconteceu de novo agora?'. A resposta mora em correlação: um AssumeRole pode ser legítimo sozinho, e criminoso quando combinado com kms:Decrypt cinco minutos depois e GetObject em bucket que ninguém daquela role deveria abrir.

O pilar clássico é o log de plano de controle: cada chamada de API, assinada, com principal ARN, source IP, user agent, request parameters e response elements. Em AWS isso é o CloudTrail; em Azure é o Activity Log; em GCP é o Cloud Audit Logs. Esse é o log que responde 'quem chamou o quê, quando, e qual foi o resultado'. Sem ele, o incidente vira palpite.

CloudTrail por padrão grava eventos de gestão (criar IAM user, deletar bucket) na trilha da conta, e mantém os últimos 90 dias em console. Para forense real, vale criar uma trilha multi-regional que escreve em S3 com object lock, e adiciona Lake ou um SIEM em cima para query e retenção mais longa.

CloudTrail não vê tudo. Ele registra a chamada de API, não o que aconteceu dentro dela nem o pacote que passou pela rede. Para fechar o buraco, três fontes viram obrigatórias.

Coletar tudo e deixar cada conta com seu bucket é receita para o log sumir no primeiro incidente. O desenho certo é fan-out: cada conta escreve seu log em S3 (ou equivalente) com KMS, e um lake agregador ou um SIEM corporativo puxa de tudo para query única.

Retenção é onde a maioria dos times escorrega. Logs de gestão precisam de 90 dias quente (query rápida) e 365 dias frio (S3 + Glacier). Logs de fluxo VPC, dependendo do volume, viram 30 dias quente e 180 dias frio. Logs de auditoria que vão virar evidência legal pedem object lock (WORM) para impedir alteração retroativa - sem isso, atacante com acesso de escrita apaga os próprios rastros.

A camada de detecção tem três sabores. Regras determinísticas (signature) disparam em assinatura conhecida: ConsoleLogin sem MFA, root API key em uso, disable de CloudTrail. ML / anomalias disparam em desvio de baseline (login de região nunca vista, listagem massiva de buckets por usuário que normalmente lista três). Hunting é o humano procurando o que ninguém pensou em regra.

GuardDuty combina os três sabores numa só assinatura gerenciada: consome CloudTrail, VPC Flow Logs e DNS, manda findings para EventBridge ou Security Hub. A integração típica é o Detective entrar para investigação (grafo de entidade + timeline), o Security Hub agregar com Prowler/Inspector, e o SOAR (Step Functions, Tines, Torq) disparar runbook. O segredo é manter a regra fora do SIEM quando o SIEM agrega mal, e usar GuardDuty para 80% dos achados óbvios.

O SIEM (OpenSearch, Splunk, Elastic, Datadog Cloud SIEM) é onde a correlação acontece. Cada fonte (CloudTrail, GuardDuty, flow logs, audit k8s, EDR) vira um stream indexado, com parser próprio e campo canônico (time, actor, target, action, result). A regra do SIEM cruza fontes: AssumeRole IAM nova + CloudTrail GetSecretValue + bucket público tocado em <5 min = sessão suspeita.

Para reduzir custo e ruído, dois hábitos dão retorno alto. Primeiro, tier de armazenamento: quentes no SIEM (30 dias), frios em S3 (Iceberg, Parquet) com Athena ou OpenSearch Serverless consultando sob demanda. Segundo, detecção gerenciada para o que você não tem equipe de manter: GuardDuty cobre 80% dos achados óbvios, CSPM cobre drift de configuração, CWPP cobre runtime. SIEM fica para o que é house-specific.