When security logs disagree about what happened first, compare the source timestamp with the time the record reached your logging system. A late-arriving record and an inaccurate device clock are different problems. Sorting every event by one displayed time can turn a collection problem into a misleading incident narrative.
For an IT team or MSP reconstructing activity across identity, endpoint, application, and network systems, the aim is to establish which sequence the evidence supports. Preserve the original records, understand what each time field represents, and state uncertainty where the clocks or collection path cannot be verified.
Which time is the log showing?
A record may carry several times: when the source says an event occurred, when a collector received the record, and when the logging platform made it available for search. Field names and meanings depend on the source and platform. An alert creation time adds another milestone: when a detection was produced, which may be later than the underlying activity.
As a concrete platform example, Microsoft's Azure Monitor documentation distinguishes TimeGenerated, _TimeReceived, and ingestion_time(). It describes collection, upload, network, and processing delays. It also documents circumstances in which a missing or out-of-range source time is replaced. That is a reason to inspect the field's actual behavior, rather than infer its meaning from its label.
A late login record can reverse the apparent story
Consider this hypothetical investigation. Both source clocks have been checked against a reliable common time reference, and both records use UTC on the same date. These invented times illustrate collection behavior; they are not a customer incident or a service-performance target.
| Record | Source event time, UTC | Collector receipt time, UTC |
|---|---|---|
| Portal sign-in | 14:00:00 | 14:03:00 |
| Application file download | 14:01:00 | 14:01:05 |
Receipt order puts the download first. The checked source times put the sign-in first. The three-minute gap on the login record tells the investigator to examine how that record was collected and delivered; it does not establish that authentication happened after the download.
Chronology also does not establish causation. Before linking these events, check the relevant account, session or request identifiers, application context, and other evidence. A matching username and a convenient sequence are not enough to prove that the same session performed both actions.
Clock error needs a different explanation
Now suppose a source reports an event time later than the collector's receipt time. Ordinary positive delivery delay alone cannot explain that relationship. Check the source clock, the collector clock, the time-zone interpretation, and the parser before calculating a latency figure.
NIST SP 800-92 explains that inaccurate host clocks can make events appear in the wrong order across systems. It recommends keeping logging-system clocks aligned to a common time source. This is foundational guidance, not a promise that every timestamp already collected is accurate.
Convert times to a common reference such as UTC for comparison, while retaining the original value and offset. Converting a time zone does not repair a fast or slow clock. A synchronization check performed today also does not, by itself, prove the clock was correct during yesterday's incident.
The syslog standard's optional time-quality fields can indicate whether the source knows its time zone, whether it is synchronized, and its expected accuracy. Look for that evidence when available, but do not assume every source supplies it or every pipeline retains it.
Keep the uncertainty visible
When investigating an offset, keep the original log intact and record any correction separately with its basis, affected interval, and confidence. Do not silently rewrite evidence to make the timeline look consistent. If the uncertainty is larger than the gap between two events, describe their order as unresolved unless other evidence establishes it.
Review search windows as well as timestamps. A record arriving now may describe older activity, so a narrow event-time search can omit it. Conversely, searching only by receipt time can hide when the underlying activity occurred. Check both dimensions where the platform supports them, and document which field the investigation used.
Before relying on a detection that joins events from multiple sources, trace an approved, harmless test action through the pipeline. Check the source record, parsed fields, receipt time, and resulting detection. This helps expose missing fields, delayed delivery, or assumptions about time windows without turning an unresolved incident into a clock experiment.
Make timing part of the monitoring scope
Network Box USA's SIEM capability supports centralized logging, normalization, correlation, and investigation within qualifying Edge Defense and NBX MDR services. It is not sold as a standalone service. Connected sources, clock administration, collection monitoring, and escalation responsibilities should be agreed during solution design.
If your team needs to review whether its security logs can support a defensible incident timeline, contact Network Box USA to discuss the relevant sources and monitoring responsibilities.