When a packet capture, a firewall log and a SIEM alert describe the same incident, their timestamps rarely agree. Here is what that looks like. The timeline below is constructed for illustration, not taken from a real case, but anyone who has sat through an incident review will recognize the shape of it.
| System | Reported time | Where the time comes from |
|---|---|---|
| Packet capture (GPS-disciplined) | 14:02:07.331 | Hardware timestamp at the wire |
| Firewall (NTP, drifting) | 14:02:09 | Drifting clock, one-second resolution |
| EDR agent | 14:01:58 | Endpoint clock nobody has checked |
| SIEM | 14:02:11 | Time the record arrived, not the time of the event |
Four systems, one event, thirteen seconds of disagreement. Now ask the question the review actually turns on: which came first, the process or the connection? Read the EDR against the capture and the process started nine seconds before the connection. But nobody has checked the endpoint’s clock. If it runs ten seconds slow, the process started after the connection, and the story of the incident reverses.
For Canadian security teams operating across regulated sectors—from energy utilities and financial institutions to telecommunications and critical infrastructure—this ambiguity is more than an annoyance. With regulatory frameworks tightening and boards demanding defensible incident reporting, knowing when an event occurred is just as critical as knowing what happened. Yet, across distributed enterprise environments, multi-vendor tool sprawl means your packet capture, firewall, and SIEM are often speaking entirely different temporal dialects.
We have covered why timestamps matter for packet capture before. This post starts one step later: the capture clock is only one of several clocks in the investigation. What follows is why those clocks disagree, why a nanosecond figure on a data sheet does not settle the argument, and what a defensible fix looks like.
Five reasons the timestamps disagree
Every system that produces evidence stamps it from its own clock, using its own sync source, at its own point in the data path. NIST’s Guide to Computer Security Log Management puts it plainly: each host references its internal clock when it stamps a log entry, and if that clock is inaccurate, the timestamps are too. In practice the disagreement comes from five places.
- Different sync sources. One device follows GNSS, another PTP, most follow NTP, and a few follow nothing at all.
- Drift between syncs. A clock is corrected only when it hears from its source. In between it runs on its own oscillator, and when the source drops it carries on with whatever holdover it has, which is sometimes none.
- Event time versus ingest time. A log record usually carries two times: when the event happened and when the collector received it. If a view sorts on arrival, queueing and batching delays quietly reorder the story.
- Formats, time zones and precision. Seconds sit beside milliseconds and nanoseconds, local time beside UTC. Truncation alone can move an event by most of a second.
- Different points in the data path. The wire, the packet broker, the sensor and the log pipeline each see the same packet at a different moment.
None of this usually breaks anything, which is why it goes unnoticed. Security infrastructure is built to tolerate skew. Kerberos, for example, accepts a default difference of five minutes between a client clock and a domain controller. A clock that is ninety seconds out still authenticates. Tolerable for login is not good enough for forensics.
Resolution is not accuracy
A timestamp has two properties that data sheets tend to blur. Resolution is the size of the tick: how finely the clock divides time. Accuracy is the offset from true time: how far the clock sits from UTC. The two are independent.
A kitchen scale that reads to a tenth of a gram can still be ten grams out if nobody has zeroed it. Clocks work the same way. A capture device may stamp every packet from a counter that ticks every 8 nanoseconds. If the clock behind that counter is set by NTP and sits a millisecond from UTC, every one of those timestamps is a millisecond wrong, reported to nine decimal places.
On that one device the spacing between packets is still excellent. The trouble starts when you lay its capture beside evidence from another device with a different error. When a data sheet says “nanosecond timestamps,” it is almost always describing resolution.
The property that matters for evidence is traceability to UTC, which is less exotic than it sounds. It comes down to two questions: who disciplines this clock, and how do you know it is right today? If you can name the source, show the chain from that source to the device, and produce a record of the measured offset, the timestamp is traceable. If the answer is “it’s on NTP, I think,” it is a number with no error bar.
Where the timestamp is applied
The same packet can be stamped at the TAP or capture card, on the packet broker, in the sensor, or only when a log line is written. Each step away from the wire adds delay, and under load that delay varies. It is one reason how you access traffic is a design decision and not a cabling detail.
Some devices carry the timestamp inside the packet itself, in a trailer, an added header or a field of a mirroring protocol, so that it survives the trip through the packet broker layer to the tool. That only works if the consuming tool understands the format. If it does not, it may stamp the packet on arrival and discard the hardware timestamp you paid for.
We raise this as a question to ask, not a fault to assume. For every hop between the wire and the analyst’s screen: where is the timestamp applied, in what format, and does the next device read it or replace it? It is quick to prove in an evaluation, and better proven before an incident than during one.
Three ways to discipline a clock
GNSS with a pulse-per-second output. A receiver takes time directly from satellites. The US Naval Observatory states that GPS users can obtain time transfer to UTC(USNO) within 40 nanoseconds, 95 percent of the time, and NIST notes that multipath errors alone can add tens of nanoseconds at the receiver. The cost is an antenna with a clear view of the sky, a cable run to reach it, and exposure to interference. It fits the grandmaster, and the capture points whose timeline will be argued over.
PTP (IEEE 1588). PTP distributes time across the network from a grandmaster, with timestamps taken in hardware. The standard was written for sub-microsecond synchronization. The cost is network support: switches that act as boundary or transparent clocks, and a grandmaster worth following. Without them accuracy degrades quietly. Our PTP explainer covers the moving parts.
NTP. NTP runs on everything and costs almost nothing. NIST researchers found that path asymmetry typically limits NTP over wide-area networks to about a millisecond; a well-run local network does better. That is adequate for many log sources. It is the wrong tool for stamping packets that arrive microseconds apart.
None of the three is the right answer everywhere. Most sound designs use all of them: GNSS at the top, PTP to the devices that need it, NTP to everything else, and one source they all trace back to.
When time becomes the attack
Time is also an attack surface. If an attacker can shift a clock or spoof its source, evidence stops lining up, and anything that depends on time, from certificate validity to the correlation windows in detection rules, can fail in ways that look like ordinary faults. CISA’s time guidance for network operators draws the same link between time offsets and the ability to reconstruct an intrusion timeline.
Two exposures are worth knowing about. GNSS signals are weak by the time they reach the ground and can be jammed or spoofed; CISA publishes guidance on resilient timing for exactly that reason. And classic NTP and PTP exchanges carry no cryptographic proof of where they came from.
Authenticated options are arriving. Network Time Security for NTP was standardized as RFC 8915 in 2020. An equivalent for PTP is an active IETF draft, still a work in progress. Until both are routine, the practical defence is the one a good timing design gives you anyway: more than one source, holdover, and monitoring that notices when clocks stop agreeing. Detecting attacks on time is a subject of its own, and beyond this post.
The Regulatory Cost of Drift: Bill C-8 and Audit Readiness
In Canada, the regulatory landscape is shifting to demand higher standards of operational visibility and cyber resilience. Under the Critical Cyber Systems Protection Act (CCSPA / Bill C-8), designated operators are required to report cyber incidents swiftly and maintain rigorous records of system activity.
When regulators or forensic investigators examine an intrusion timeline, “approximate time” does not suffice. If your logs cannot prove traceability back to UTC—with documented error bars and synchronized timestamps across your security stack—your incident reconstruction becomes legally and operationally vulnerable. A timeline skewed by even a few seconds can obscure lateral movement, invalidate breach attribution, and complicate mandatory reporting compliance. Traceable time is no longer just a technical best practice; it is a compliance requirement.
A time contract for your evidence
The fix is not a better tool. It is a deliberate timing design, written down. We think of it as a time contract: a short document that states what every evidence source promises about its clock.
- Name an authoritative source, and name the person who owns it.
- Discipline every evidence producer from it, or record why not.
- Record each source’s sync method and estimated uncertainty. “NTP, within a few milliseconds” is a perfectly good entry. An empty cell is the problem.
- Monitor offsets and alarm on drift. A clock that was right at commissioning proves nothing about today.
- Store event time in UTC, in ISO 8601 format, and keep ingest time as a separate field. Never let one overwrite the other.
- Re-test after changes. Firmware, topology and tool upgrades all move clocks.
None of this requires replacing the tools you have. It requires knowing what each one promises, which is also the starting point for deciding where better timing would actually change an outcome.
Five questions to ask your team on Monday
What time source disciplines each of your capture points?
If the answer differs by site, or nobody is sure, that is the first entry in the contract.
Does your SIEM sort on event time or ingest time?
Check the views your analysts actually use, not only the default.
What is the worst clock offset in your security stack today, and who would notice?
If nothing measures it, the honest answer is “unknown.”
If the time source dropped for four hours, what would your timestamps be worth?
This is a holdover question, and it has a different answer for every device.
Could you show an auditor how each timestamp traces back to UTC?
Not every source needs nanoseconds. Every source needs an answer.
Where to start
If those questions were harder to answer than expected, that is normal. Timing, visibility and security tooling are usually bought by different teams, in different years, and nobody owns the clock that connects them. We work across all three.
Fixing this does not mean ripping out your existing security stack. As a Canadian value-added reseller and technical advisor, Telnet Networks works with organizations across the country to bridge the gap between visibility, precision timing, and network security. Whether you need to deploy resilient, dual-source GNSS grandmasters (such as Safran timing solutions) at primary data centers, implement software-based time distribution (like Timebeat) across virtualized environments, or audit your existing NTP and PTP hierarchies, we help you design a timing architecture you can actually defend in an audit or an incident review.
Bring us the list of your evidence sources and we will help you work out which clocks you can trust and which need attention. Talk to our team.
Telnet Networks is a Canadian value-added reseller specializing in network visibility, precision timing and network security. We work with several vendors in each of those areas, and our recommendations depend on the network in front of us.
