The alert is today.
It started in July.
An intrusion is discovered long after it begins. Whether you can investigate it at all is decided by something you did months earlier — whether anything was recording.
Rebuilding an incident timeline means answering when it started, how it got in, what it talked to and what left — and those answers live in traffic that has usually already been discarded. Logs record what each system chose to record about itself; a compromised system is a poor witness to its own compromise. The network is the one place every step had to cross, which is why retained traffic is what turns an investigation from inference into reconstruction. The constraint is simple and unforgiving: you cannot go back and record last month.
Five questions, and where each is answered.
When did this actually start?
The detection date is almost never the start date. Finding the true beginning changes the scope of everything that follows — including what has to be disclosed and to whom.
Answered by searching retained traffic backwards for the first occurrence of the behaviour, not for the alert.
How did it get in?
Until this is answered, remediation is guesswork and reinfection is likely. The initial access is usually a single, unremarkable-looking conversation.
Answered by the first inbound session to the first affected host, which requires the traffic from that day to still exist.
What did it talk to?
Lateral movement is normal-looking traffic between hosts that had no reason to talk. The pattern is the signal, and it is only visible if you have the conversations.
Answered by peer relationships over time — new pairs, unusual timing, repeated small transfers.
Did anything leave?
This is the question that determines regulatory obligations and the answer people most want to be certain about. Volume, destination and timing all matter.
Answered by outbound volume against baseline, per host, over the whole period rather than the last week.
Is it still here?
Beaconing is regular, low-volume and easy to miss in isolation. Over weeks of retained traffic the regularity becomes obvious.
Answered by looking for periodicity, which needs a long enough window to establish a period.
Can you show your working?
Insurers, regulators and boards ask for evidence, not conclusions. A retained record is a factual account; an inference from logs is an opinion.
Answered by the stored traffic itself, with its timestamps and its capture points documented.
Four steps, and one that cannot be reordered.
- 1
Fix the earliest confirmed event
Start from the hardest evidence you have and search backwards, not forwards from the alert. The alert is where you noticed, not where it began.
- 2
Establish the peer graph around it
Which hosts did the affected system talk to, and which of those relationships are new? This produces the candidate scope in one step.
- 3
Measure outbound against the host's own baseline
A server's normal egress varies enormously by role. The comparison that means something is against itself last month, not against a general rule.
- 4
Preserve before you remediate
Rebuilding a host destroys evidence. Copy the relevant capture window out first — it takes minutes and it is unrecoverable afterwards.
Why most investigations start blind
- Logs are written by the systems under investigation. The network is the one place every step had to cross, whatever each host decided to record about itself.
- On-demand capture cannot look backwards. Starting a capture when the alert fires records the aftermath. NM-Security Cyber was already recording in July.
- Retention is the whole capability. Everything in this page depends on the traffic from the start date still existing — which is a decision made months in advance.
Short answers.
How do you reconstruct a security incident timeline?
Start from the earliest confirmed event and search backwards through retained network traffic for the first occurrence of the behaviour, rather than forwards from the alert. Build the peer graph around the affected hosts to establish scope, compare outbound volume against each host's own baseline, and preserve the relevant capture window before any remediation destroys evidence.
Why are logs not enough?
Logs are produced by the systems being investigated, and record what each chose to record. A compromised host is an unreliable witness to its own compromise, and logs can be cleared. Network traffic is observed independently of the endpoints, so it survives regardless of what happened on them.
How far back do you need to keep traffic for this?
Longer than for performance work. Intrusions are frequently discovered weeks or months after they begin, and a retention window shorter than the dwell time means the start of the incident is simply not available. Where the retention line falls is where the investigation stops.
Can you investigate encrypted traffic?
Substantially, yes, without decrypting it. Who talked to whom, when, how often, how much, in which direction, with what regularity and whether the handshake succeeded are all visible. Beaconing, lateral movement and unusual egress are patterns in that metadata rather than in the payload.
Related questions.
Could you investigate something that started in July?
That is a good question to answer before you need to. We will look at what you would have to work with.