Cibersegurança e segurança da informação

Como Construir uma Linha de Tempo para Investigação de Incidentes Cibernéticos

6 min de leituraPublicado: 5 de agosto de 2026

Representação visual profissional sobre a construção de uma Linha de Tempo para investigação de incidentes na área de SOC e operações

Resposta rápida

Uma linha de tempo para investigação de incidentes é uma tabela cronológica que unifica eventos de diferentes fontes num tempo padronizado, ligando-os através de utilizadores, estações de trabalho, endereços IP, processos e sessões. Uma construção correta inclui a preservação do tempo original, conversão para UTC, indicação da fonte e fiabilidade, identificação de lacunas e distinção entre factos, interpretação e suposições.

Um incidente cibernético raramente aparece num único registo. A ligação está no sistema de identidade, a execução do processo no EDR ou Windows, a solicitação de domínio no DNS e a ligação externa no Firewall. Cada fonte descreve uma parte diferente, num formato de tempo diferente e com identificadores distintos. Sem uma linha de tempo, o investigador vê uma coleção de sinais; com uma linha de tempo, ele pode ver uma possível sequência causal.

Uma linha de tempo não é apenas uma ordenação por hora. É um processo de normalização, ligação e avaliação de fiabilidade. Um relógio desalinhado, um fuso horário incorreto ou um atraso na receção podem inverter a ordem e criar uma conclusão errada. O NIST define a gestão de registos como um processo que inclui criação, transmissão, armazenamento e acesso; cada etapa afeta a capacidade de reconstruir um evento.

Neste artigo, construiremos uma linha de tempo a partir de um cenário que inclui Windows, DNS, Firewall e EDR. Os exemplos são independentes de um produto específico e podem ser implementados numa folha de cálculo, SIEM, Notebook ou ferramenta DFIR.

Porque é que a Linha de Tempo é o Coração da Investigação

A linha de tempo responde a perguntas que não podem ser resolvidas com um único evento: qual foi o Initial Access, que processo criou a conexão, a ligação precedeu a execução, o que aconteceu após o isolamento e se o mesmo utilizador operou em ativos adicionais.

Também revela lacunas. Se o EDR mostra a execução de um ficheiro, mas não há evento de criação de processo no Windows, o Audit pode não estar ativado, o registo pode ter sido apagado, o evento pode ter sido filtrado ou os identificadores de tempo podem não estar alinhados. A própria lacuna é uma descoberta.

Numa investigação complexa, é aconselhável manter duas linhas de tempo: uma Master Timeline que inclui os eventos centrais, e uma Timeline detalhada para cada ativo ou fonte. Assim, o relatório permanece legível sem perder os dados.

Normalização de Tempos e Fontes

Mantenha sempre dois campos: Original Timestamp conforme apareceu na origem, e Normalized Timestamp em UTC. Indique o fuso horário original, o desvio de relógio conhecido e o tempo de ingestão no SIEM. Não sobrescreva o tempo original, pois é necessário para auditorias e para resolver inconsistências.

Diferencie entre tempo do evento e tempo de Ingestão. Um Firewall pode enviar um registo com atraso, um Agent pode estar Offline e carregar dados mais tarde, e um produto cloud pode calcular a Deteção após o evento. Ordenar apenas pelo tempo de ingestão pode estar errado.

Verifique a sincronização NTP, configurações de Daylight Saving, formatos com/sem Offset, milissegundos e campos que contêm tempo de criação versus tempo de atualização. Ao alterar o tempo do sistema, documente o desvio e não tente “corrigir” silenciosamente.

Conexão de Utilizadores, Hosts, IP e Processos

Eventos de diferentes fontes são conectados usando Pivot Keys. Identidade: UPN, SID, Object ID, Session ID. Estação: hostname, Device ID, Agent ID, endereço MAC. Rede: IP, NAT translation, port, protocol. Processo: PID, Parent PID, Process GUID, hash e linha de comando.

O PID por si só não é um identificador estável ao longo do tempo, pois o sistema operativo pode reutilizá-lo. No Windows, o Process GUID do Sysmon ou a combinação Host + PID + tempo ajudam mais. Um endereço IP interno pode transitar entre estações via DHCP, por isso é necessário cruzar com Lease ou telemetria adicional.

Em cada linha, adicione um campo “Entity Link”: por que o evento está relacionado ao anterior. Por exemplo: “A query DNS foi criada pelo PID 4120, que é um filho de powershell.exe da linha anterior”. Uma ligação explícita impede o leitor de assumir uma conexão não comprovada.

Separação entre Facto, Interpretação e Suposição

Facto: “Às 10:14:22 o EDR registou powershell.exe com Parent winword.exe.” Interpretação: “A sequência corresponde à possibilidade de execução de código a partir de um documento.” Suposição: “O utilizador pode ter aberto um ficheiro de Phishing.” A separação é crítica para que o relatório não apresente uma suposição como se fosse uma evidência.

É possível adicionar uma coluna de Confidence: alta quando várias fontes independentes apoiam; média quando uma fonte de alta qualidade apoia; baixa quando os dados são parciais ou dependem de uma suposição. O nível de confiança não é uma pontuação matemática obrigatória, mas uma forma de comunicar incertezas.

MITRE ATT&CK pode ser adicionado após a compreensão do evento para descrever técnicas, mas o mapeamento não deve ser usado para preencher lacunas. O facto de existir PowerShell não prova Initial Access ou Persistence.

Identificação de Lacunas e Contradições

Procure falhas nos tempos, eventos que aparecem apenas numa fonte, endereços que não correspondem a NAT, utilizadores em diferentes formatos e resultados opostos. Uma lacuna de cinco minutos antes da primeira conexão pode conter a ação mais importante.

Quando duas fontes apresentam tempos diferentes, verifique Clock Skew, Time Zone, tempo de escrita versus tempo de ingestão, arredondamento e cache. Mantenha as duas versões e indique qual foi usada para ordenar e porquê.

Construa uma “lista de ausências”: registos de Proxy não guardados, Process Creation não ativado, o EDR estava Offline, ou não há acesso ao Mailbox Audit. A lista ajuda a entender as limitações da conclusão e a melhorar o Logging posteriormente.

Apresentação da Linha de Tempo no Relatório

A linha de tempo num relatório de gestão deve incluir apenas eventos que mudam a compreensão do incidente: acesso inicial, execução, persistência, movimento lateral, acesso a informações, contenção e recuperação. Um anexo técnico pode incluir todos os registos.

Para cada linha, é recomendado apresentar: UTC, tempo original, fonte, entidade, evento, evidência/identificador, interpretação e nível de confiança. Use uma linguagem consistente e verbos precisos: “criado”, “bloqueado”, “falhou”, “observado” — não “comprometido” sem prova.

Anexe uma linha de tempo resumida também ao Ticket para que o próximo analista possa continuar sem ler todas as notas.

Cenário: Windows, DNS, Firewall e EDR

UTC	Fonte	Entidade	Evento	Ligação e Interpretação
08:41:03	Windows Security	WS-17 / user1	Login interativo bem-sucedido	Início da sessão; verificar fonte e Logon ID
08:43:18	EDR	WINWORD.EXE	Criação de powershell.exe	Árvore de processos indica execução a partir de um documento
08:43:20	EDR	powershell.exe	Linha de comando codificada	Precisa ser descodificada em ambiente seguro e fonte guardada
08:43:22	DNS	WS-17	Query para new-example-domain.tld	Mesmo Host, dois segundos após a execução
08:43:23	Firewall	10.0.4.17	Conexão TLS para IP externo	O IP corresponde à resposta DNS; NAT verificado
08:44:01	EDR	powershell.exe	Criação de ficheiro na pasta Temp	Hash guardado; ainda não determinado se é malicioso
08:47:55	Microsoft Sentinel	user1 / WS-17	Incidente criado	Tempo de Deteção posterior ao tempo dos eventos
09:02:11	EDR	WS-17	Isolamento da estação bem-sucedido	Ponto de Contenção; verificar conexões posteriores

Checklist Prática

Guardei o tempo original e o tempo UTC.
Diferenciei Event Time de Ingestion Time.
Documentei a fonte e o campo identificador.
Liguei entidades usando identificadores fiáveis.
Separei factos de interpretações.
Indiquei lacunas e contradições.
Adicionei Confidence.
Criei uma Timeline resumida e um anexo detalhado.

Erros Comuns

Ordenar apenas pelo tempo de ingestão.
Converter o tempo sem guardar o valor original.
Ligar eventos apenas com base em IP dinâmico.
Escrever uma suposição como se fosse um facto.
Sobrecargar a Master Timeline com milhares de eventos sem filtragem.

Resumo e CTA

Pegue num cenário de laboratório e construa uma Linha de Tempo manual a partir de quatro fontes. Depois, compare-o com o processo de investigação no primeiro artigo e verifique quais campos devem ser adicionados ao Playbook da equipa. No curso Cybersecurity & AI da HPI, as competências de registos, redes e SIEM são aprendidas como parte do exercício prático de investigação de incidentes.

Perguntas frequentes

Utiliza-se sempre UTC?

É recomendável normalizar para UTC para unificar fontes, mas também guardar o tempo e o Offset originais e apresentar o tempo local conforme a necessidade do negócio.

O que fazer quando não há sincronização de relógio?

Avalie o Clock Skew usando um evento comum ou uma fonte fiável, documente a diferença e guarde os tempos originais. Não altere evidências sem documentação.

Que ferramenta usar para construir uma Linha de Tempo?

Pode começar com uma folha de cálculo ou SIEM. Em investigações maiores, usam-se ferramentas DFIR ou Notebook. A ferramenta é menos importante que os campos, a normalização e a ligação.

Quantos eventos incluir?

Na Master Timeline, incluem-se eventos essenciais. Todos os registos são guardados num anexo ou numa base de dados de evidências.

A Linha de Tempo prova causalidade?

Não necessariamente. A proximidade no tempo fortalece a possibilidade de uma ligação, mas é necessário um identificador ou evidência adicional para determinar que um processo causou outro.