Linha do tempo do incidente: juntando logs de quatro fontes

O incidente foi contido. Vem então a pergunta que decide tudo o que acontece depois — a conversa com o jurídico, com a seguradora, com o cliente e, havendo dado pessoal, com a autoridade. A pergunta é sempre a mesma: o que aconteceu, e em que ordem?

Responder isso significa montar a linha do tempo do incidente. E é aí que a maioria das empresas descobre que tem quatro consoles, quatro formatos de registro, três fusos horários e nenhuma história.

A tese em uma frase: a linha do tempo do incidente não é um produto que se compra — é um procedimento; e o que impede a maioria das empresas de montá-la não é falta de SIEM, é relógio desalinhado, retenção vencida e ausência de uma chave que ligue os eventos entre si.

O relógio é o pré-requisito que ninguém confere

É a etapa mais chata e a que estraga todo o resto quando falha.

Fontes diferentes gravam o tempo de formas diferentes. O provedor de nuvem quase sempre grava em UTC. O servidor local grava em horário de Brasília. Um appliance antigo grava no horário que alguém configurou na instalação, e que já derivou alguns minutos. O resultado é previsível: dois registros do mesmo evento aparecem separados por três horas, e a ordem dos fatos sai errada.

A regra que resolve é simples de enunciar e trabalhosa de implantar. Todas as fontes no mesmo servidor de tempo. Tudo normalizado para UTC na análise. E o fuso declarado ao lado de cada fonte. O horário local serve para conversar com pessoas; a reconstituição se faz em UTC.

O NIST trata isso como parte do processo forense desde o SP 800-86, de 2006. E vale registrar o que a data significa: a orientação continua valendo porque o problema não mudou. O SP 800-92, sobre gestão de logs, também é de 2006 — a revisão r1 está em rascunho público desde outubro de 2023 e ainda não foi finalizada.

A chave que liga os eventos na linha do tempo do incidente

Cada fonte responde a uma pergunta diferente e carrega um identificador diferente. A reconstituição se monta cruzando esses identificadores — não existe mágica além disso.

Duas observações que valem mais do que a tabela.

A primeira: o identificador que costuma faltar é o usuário. Log de rede tem IP, e IP em rede com NAT ou DHCP não identifica pessoa sozinho. Ele exige uma segunda consulta — que precisa existir e ter retenção compatível.

A segunda: log de aplicação é o mais frequentemente desligado, e é o único que responde "que dado foi acessado". Sem ele, você consegue provar a invasão e não consegue dizer o que vazou. Para a comunicação prevista na LGPD, essa diferença é enorme, como já detalhei em notificação de incidente.

Retenção: o log que existia e venceu

Este é o item que transforma uma investigação possível em impossível, e ele é decidido meses antes, numa planilha de custos.

O relatório da IBM com o Ponemon mediu 241 dias como ciclo médio para identificar e conter uma violação em 2025 — o menor em nove anos. Confronte esse número com a retenção padrão de muitas ferramentas, que fica entre 7 e 30 dias. A conclusão é aritmética: no caso médio, a evidência já não existe quando alguém vai procurar.

O exercício que recomendo é chato e leva uma tarde. Liste as fontes, anote há quanto tempo cada uma guarda registro, e marque em vermelho tudo abaixo de 90 dias. Essa tabela vale mais numa renegociação do que qualquer discussão de funcionalidade — e é uma das cláusulas que defendo em incidente com múltiplos fornecedores.

Como montar a linha do tempo do incidente sem comprar nada

Uma planilha resolve o primeiro caso. Sério.

Uma linha por evento, e sempre estas colunas: horário em UTC, fonte, ator, ativo, ação, onde está a evidência, e o seu grau de confiança. A última é a que separa reconstituição de narrativa. Marque "confirmado" quando há registro e "inferido" quando você está preenchendo o vazio com raciocínio. Misturar os dois é como se perde credibilidade na conversa com um auditor.

Ordene por horário, leia de cima a baixo e conte a história em voz alta. Onde a história não fizer sentido, existe um evento faltando — e você acabou de encontrar a próxima pergunta.

Preserve antes de mexer. Isolar um equipamento mantém disco e memória; matar processo, apagar arquivo e reinstalar destroem o rastro. Essa é a mesma fronteira que descrevi em contenção automática, e ela vale igual quando quem age é uma pessoa apressada.

O buraco também é achado

Um hábito que muda a qualidade do relatório final: registre as lacunas com a mesma seriedade dos eventos encontrados.

"Não há log de autenticação da aplicação X entre os dias 3 e 11" é um resultado. Ele diz que aquele caminho não é observável e que ninguém vai enxergar um próximo ataque por ali. E deixa uma decisão pendente: ligar o log, aumentar a retenção ou exigir a entrega do fornecedor.

Relatório que só mostra o que foi encontrado passa uma impressão falsa de completude. E completude falsa é pior do que lacuna declarada, porque impede a pergunta seguinte.

Quando isso vira SIEM

Sendo honesto sobre o limite do método manual: ele não escala.

Montar a linha do tempo do incidente na mão é viável uma vez, cansativo três vezes e insustentável toda semana. O ponto de virada não é o tamanho da empresa, é a frequência — e o sinal de que chegou a hora é você repetir a mesma coleta manual todo mês.

Aí passa a fazer sentido a discussão de ferramenta, que o blog já cobre em SIEM e XDR. Só que a ordem importa: quem já montou a linha do tempo na mão sabe exatamente quais fontes precisa integrar e qual retenção contratar. Quem nunca montou compra um catálogo e descobre depois que a fonte que faltava continua faltando.

O ponto que fica

A capacidade de dizer o que aconteceu e em que ordem não vem da ferramenta mais cara. Vem de três coisas baratas, decididas antes: relógio igual em todo lugar, um identificador que atravesse as fontes e retenção maior que o seu tempo de descoberta.

Nenhuma das três aparece em demonstração de produto. E as três decidem se o plano de resposta a incidentes termina com um relatório ou com uma suposição bem escrita.

A pergunta de verificação, para fazer hoje e não depois: se um incidente tivesse começado há quatro meses, quais das suas fontes ainda teriam o registro?