If this isn't your field, here is the short version.

When someone breaks into an organization's computers, the investigation runs on logs: the records each machine keeps of what it did and when. The records flow to a central collector, where software detectors read them for the security team (a SOC, or security operations center) and decide whether an attack happened. Order matters. An attack followed by the defender's response is one story; the response before the attack is another.

But each time comes from that machine's own clock, clocks drift apart, and records can arrive late, out of order or not at all. In 2026 two researchers, Heinzl and Nissl, audited dozens of published papers on these detectors and found that none of the systems they sampled states a numeric limit on how far a clock may be off 1. That counts what papers say, not what detectors do.

This essay designs the test: take OpTC, a public archive of a recorded attack exercise released by DARPA, a US defense research agency 3; shift its clocks and delay its records on purpose; and find where a research detector called KAIROS, published in 2024 2, changes its answer. Nothing has been run. It matters because incident reports are written from these timelines, and someone acts on them.

Clock skew and delivery delay may flip a provenance detector's verdict (its call on whether an attack happened; provenance detectors trace which program touched which file or network connection) at specific, measurable thresholds rather than wearing it down gradually. The surveyed literature hasn't measured where. A 2026 Systematization of Knowledge (SoK), a kind of survey paper that audits a research field, by Heinzl and Nissl found that in 28 of 38 audited provenance-era detector papers, capture or stored evidence is trusted or its manipulation is placed out of scope, and that among 52 audited host- detector papers, four describe an input-ordering condition or convention and none says which conclusions survive delayed or missing records 1. That is an audit of stated assumptions, not a measurement of failures. This essay proposes the measurement, in two parts that must stay separate: offline perturbation of the static DARPA OpTC traces (a public archive of computer activity recorded during a two-week attack exercise) to draw detector stability curves, and live benchmarking of collectors (the services that gather logs from many machines into one place) under load to measure the timing noise real deployments actually produce. The output is a stability metric that sits beside True Positive Rate (TPR) and False Positive Rate (FPR), the usual measures of how many real attacks a detector catches and how many false alarms it raises, not instead of them.

• The audit: 28 of 38 provenance-era detector papers trust the evidence; 4 of 52 host- detector papers describe an input-ordering convention; none states which conclusions survive delivery failures 1.
• The risk: Collectors add variable delay and reordering under load, and a detector that orders by arrival can be handed the response before the attack.
• The study: Perturb archived OpTC traces offline to test the detectors; measure live collectors separately to learn how much perturbation is realistic. Mixing the two hides whose fault a flipped verdict was.
• The handoff: The protocol is written for a grad student with a semester and a GPU. Run the baseline first, and stop if it doesn't fire.

• For SOC managers: TPR and FPR benchmarks assume the timeline arrived intact. Stability under realistic timing noise is a separate number, and nobody is quoting it to you.
• For incident responders: A timestamp in a report reads as a fact. It's an estimate with an error bar nobody drew.
• For tool developers: If your detector windows by event time, its clock bounds and ingestion semantics belong in the documentation, not in the reader's imagination.

Forensic analysis is the reconstruction of causal chains, and a causal chain is only as good as the order of its events. In a standard computing environment, time isn't one abstraction. It's several models sharing a name. Host-based detectors often order events by the timestamp embedded in the record, not by when the record reached the collector 1. The gap between event time (when the host says it happened) and ingestion time (when the collector heard about it) is where causality gets proved or lost.

Standard Network Time Protocol (NTP) or Windows Time Service (W32Time), two common services computers use to set their clocks over a network, isn't automatically good enough for forensic ordering. Microsoft documents specific support boundaries: Windows 10, Server 2016 and later can deliver 1 second, 50 millisecond or 1 millisecond accuracy, each tier only when its own documented requirements are met 4. The application writing the log rarely knows which of those it's living under.

Picture the timeline. An attack event (A) and a response event (B) both occur on Host 1, A at t=100ms and B at t=150ms. A's trip to the collector takes 200ms; B's takes 10ms. The collector receives B first. Ask the ingestion order what happened and it says the defender moved before the attacker did, and a detector that trusts that order may hand down the wrong verdict. Events in the collector are older than they appear. Hold on to A and B. They come back at the end.

Standard definitions of forensic time distinguish wall-clock time (UTC-synchronized), local process time and network time (delivery latency) 1. Provenance-era detectors, as the literature describes them, mostly take capture-layer event time as given 1. Skew the source clock, or let the delivery path reorder things, and the provenance graph gets built on the wrong premises.

A timestamp is a claim the host makes about itself. Detectors that sort by event time accept the claim, which assumes the host clock was right. Detectors that sort by arrival assume the network is a FIFO queue (first in, first out). Both assumptions have failure modes, and the SoK's point is that detector papers rarely say which one they're making, let alone how much error it tolerates 1.

Heinzl and Nissl's 2026 SoK audits the stated temporal assumptions of host-based intrusion detectors 1. It uses two different populations, and they're worth keeping apart, because swapping them is the easiest mistake in this whole area. (This essay's first draft made it.)

• Evidence trust: Of 38 eligible provenance-era detector papers, 28 state that the kernel, the audit framework or the stored logs are trusted, rely on the capture system's guarantees, or place manipulation of the evidence out of scope 1.
• Delivery: Of 52 papers whose pipelines consume host event records, four describe an input-ordering condition or convention, and none specifies conditions under which its conclusions stay valid across a stated class of delayed or missing records 1. No sampled system states a numeric bound on clock offset 1.

Those are findings about what papers say, from a selected sample, not about how deployed detectors behave. The SoK is careful about that, and so should anyone quoting it be. What the audit establishes is the absence of a guarantee. Whether the absence costs anything is the open question.

Real collectors don't promise order under load, and their documentation says as much. Windows Event Forwarding (WEF) offers delivery configurations with batching timeouts of 30 seconds, 15 minutes and 6 hours 5. Those are configuration limits, not measured latencies: they tell you how long a batch may wait, not when your event arrives. TCP guarantees in-order delivery of a byte stream within one connection 7. It promises nothing across connections, so multi-worker fan-in, per-CPU buffering and clock steps reorder records anyway.

The audit's split between evidence integrity (is the stored record trustworthy?) and delivery (did it arrive on time, in order, at all?) is the useful one 1. A detector can score well on clean data and fall over on realistic delivery noise, and the literature, as the SoK reads it, has measured the first and assumed the second.

The SoK's evidence ledger shows how thin the clock evidence gets 12. Its keyword search for KAIROS's clock assumptions turned up exactly one passage containing "drift," and it's about concept drift: the benign behavior changing over time. The coders, correctly, marked the clock question "not found in full text." (Concept drift and clock drift share a word and very little else.)

Testing whether timing noise produces cliff-like verdict flips takes two experiments: offline perturbation of recorded OpTC traces, and live measurement of collector lag under load. Why not run them together? Because then you can't tell whose fault the verdict was. The offline sweep tests the detector's logic. The live benchmark tests the collection infrastructure. A stability curve is a property of the first, a latency distribution is a property of the second, and the risk is where they overlap.

DARPA OpTC is a static archive. The red team's evaluation ran on a thousand Windows 10 hosts for two weeks (a red team is the group hired to play the attackers); space limits meant data from five hundred of them was kept, approximately a terabyte of compressed JSON 3. Each endpoint sensor sent JSON records to Kafka, where a translation server turned them into eCAR records 3. The release includes the red team's ground truth (OpTCRedTeamGroundTruth.pdf) 3. Static means the timestamps are fixed and the hosts are gone, so the traces can't be recaptured through live Sysmon agents; perturbation means editing the records and their order before the detector reads them.

The live half runs standard agents under stated load profiles and records the gap between event generation and collection. Keep the layers apart when you assign blame. Sysmon produces events and WEF forwards them; auditd produces events and rsyslog forwards them. (Sysmon logs activity on Windows machines, auditd on Linux ones; WEF and rsyslog carry the records to the collector.) ETW callbacks have documented exceptions where events arrive out of order relative to their timestamps 6, and that's a producer-side fact, not a network one.

The offline perturbations are per-host clock offset, delivery delay, and record loss. Per-host matters: shifting every clock by the same amount changes nothing about relative order, while shifting one host's clock changes every cross-host correlation it takes part in. Loss needs care too. Dropping a record doesn't simulate network packet loss, because TCP retransmits lost packets. It simulates what TCP can't fix: collector queue overflow, a source log overwritten before collection, retention, disabled capture. Those have different recovery stories, so the sweep should label which one it means.

The lab is three machines: one generating traffic, one collecting, one running the detector. For the offline half, the pipeline reads the OpTC corpus, applies the perturbation script below, and feeds the detector one of two views of the result.

"Verdict consistency" needs a unit before it means anything. Same malicious host? Same anomalous windows? Same reconstructed chain? Same event-level labels? Those can disagree, and a study that doesn't pick one can report whichever moved.

The unit here is the attack chain. For each attack the red team recorded in the OpTC ground truth, the verdict is whether the detector raises an alarm that covers it 3. That's the unit that maps to "incident verdict" in the title, and it's cheap to score, because the ground truth is already written down by the people who ran the attacks. Each perturbed run reports two numbers per chain: agreement with the unperturbed baseline, and accuracy against ground truth. Agreement alone would reward a detector that's consistently wrong.

Two secondary measures ride along: chronology (does the reconstructed order of the chain's events survive?) and detection latency. A detector can keep the verdict and scramble the story, and an incident report needs both.

Want to sweep a detector? First prove it fires.

Run the zero-perturbation baseline repeatedly, with different seeds (the starting values for the run's random choices), on the same data. Then apply two stop conditions, decided before you look:

1. If it detects nothing, stop. If the baseline flags no attack chain, there's no verdict to flip. Report that and go no further. This isn't hypothetical: the ORTHRUS authors (ORTHRUS is a later detector, published at USENIX Security 2025) reran KAIROS with its original code and report zero true positives at the node level on the DARPA E5 CADETS and THEIA datasets 11. Those are E5 datasets, not OpTC, but the lesson travels.
2. If the seeds disagree with each other, stop. If seed-to-seed variance in chain-level verdicts is as large as the effect H1 is looking for (10 percentage points), no threshold claim can be separated from noise. Report the variance. It's a finding.

Only a baseline that fires, and fires the same way each time, earns a sweep. Otherwise someone spends three weeks measuring the stability of a detector that never detected anything.

The central question is whether stability is step-like or smooth. Call the step-like answer the Cliff Hypothesis (H1): verdict consistency changes by at least 10 percentage points within a 100ms span of perturbation, instead of declining steadily across a wide range.

Some cliffs are expected, and finding one isn't news. KAIROS groups edges into 15-minute time windows and queues windows with overlapping suspicious nodes into anomaly queues 2. A window boundary is a cliff by construction, and it's closer than the window's width suggests: an event at 12:14:59.999 crosses into the next window after 2 milliseconds of positive skew. So the question H1 asks is not whether the boundary cliff exists. It's whether there are others. A student who finds the 15-minute step and writes it up as a discovery has rediscovered the config file.

That shapes the sweep. Record, for every perturbation, whether any attack-chain edge crossed a window boundary. Then compare the runs that crossed with the runs that didn't. If verdicts move only with crossings, the windows are the whole story (H2). If they move without crossings, something else is sensitive: the Temporal Graph Network memory that KAIROS uses for edge embeddings 2, the order in which it ingests edges (chronologically, as they appear in the stream 1 ), or the anomaly queue.

The test for H1 shouldn't be "did we see a 10-point drop?" A steep smooth curve can do that, and a real discontinuity can be smaller. Fit change-point models against flexible smooth alternatives, across a dense sweep, with confidence intervals from the repeated baseline runs, and let the comparison decide.

H3 concerns delivery blindness: a detector that sorts by event time should be unaffected by delivery delay alone. For a detector that reads the whole dataset, sorts it by immutable timestamps and only then evaluates, that's true by construction. Nothing to test. The interesting case is streaming. A streaming detector has to decide when a window is complete, so watermarks, timeouts, partial windows and late-event handling can all let arrival order leak back in. H3 should be tested there, with delay-only perturbation and the embedded timestamps untouched.

Cross-host chains should be more fragile than single-host ones. Single-host correlation compares timestamps from one clock; cross-host correlation compares two clocks that disagree. Give Host A and Host B 100ms of relative skew and causally linked events between them may come out unordered.

Basin et al. (2014) work out how to monitor properties over imprecise timestamps 9. Michael et al. (2020) ask whether forensic conclusions survive approximated audit logs 10. Neither draws detector-specific stability curves for current provenance detectors. That's the gap this study would fill.

Until the curves exist, ask vendors for a time model declaration: does the detector order by event time, by arrival, or a mix; what clock skew does it tolerate before performance degrades; what happens when records arrive late or not at all; which batch timeouts sit upstream of it. That follows directly from the audit 1. If the documentation doesn't say, assume the worst. Among the 52 audited host-detector papers, only four described an input-ordering condition at all 1.

Incident narratives should carry error bars on their timestamps. Not one house number for every source: a Windows endpoint with poor synchronization, a well-run Precision Time

Protocol (PTP) environment and a host that just stepped its clock shouldn't share a bar. The interval should come from that source's observed or bounded clock offset, its timestamp precision and its collection path, and the report should say where the number came from. Better to draw the bars in the first report than to find them as afterwit in the post-incident review.

Stability complements TPR and FPR; it doesn't replace them. TPR tells you how a detector does on clean data. Stability tells you how much of that survives realistic noise. Which would you rather defend in a post-incident review: 99% TPR with one chain-level verdict in three flipping at 100ms of skew, or 90% TPR that holds steady to 500ms? Depends on your clocks, which is the point. You can't choose without the curve.

A procurement checklist, then:

1. Does the detector order by event time, arrival, or both?
2. What is its stated clock-skew tolerance, and how was it measured?
3. What happens when records arrive out of order, late, or never?
4. Which batch timeouts sit between your hosts and the detector?

Accuracy assumes the evidence arrived as it happened. Stability asks what's left of the verdict when it didn't. Clocks drift and queues fill. The field measures the first and assumes the second.

Back to A and B. On the collector's clock, the defender answered an attack that hadn't happened yet. Someone writing the incident report from that timeline makes a confident, specific, wrong claim, and the reader acts on it. Whether real detectors make that mistake at 2ms, at 15 minutes, or never, is a measurement nobody in the surveyed literature has taken.

The thesis isn't settled. If the curve is smooth, the work is continuous mitigation: tighter clocks, shorter queues. If it's cliff-edged, the work is finding the edges and staying off them. Either way, if KAIROS fails at 15 minutes, 15 minutes is the operational limit, and if it fails at 1 second, 1 second is. Without the curve those limits are guesses. The guesses have had a long run.

1. H1 (Cliff): Away from window boundaries, verdict consistency still shows steps: at least 10 percentage points of change within 100ms of perturbation.
   • Falsifier: Across a dense sweep with the baseline gate passed, smooth models are preferred over change-point models for runs where no attack edge crosses a window boundary.
2. H2 (Window sensitivity): KAIROS's chain-level verdicts change only when attack edges cross 15-minute window boundaries.
   • Falsifier: Verdict change beyond baseline seed variance in runs where no attack edge crosses a boundary.
3. H3 (Delivery blindness): A streaming detector that orders by event time is unaffected by delivery delay alone.
   • Falsifier: Its chain-level verdicts change under delay-only perturbation with embedded timestamps held fixed.

Run this on copies of archived traces, never on production logs. The point of the script is that each perturbation lands in exactly one place. The embedded timestamp carries clock offset and nothing else. Arrival order carries delivery delay and nothing else. Mix them and a faithful implementation reports H3 falsified by a bug.

FUNCTION PerturbTrace(events, cfg):
    # events: archived records in recorded order; each has host_id, event_time
    # cfg: { host_offset[host_id], worker_delay[worker], workers, drop_prob, seed }
    rng = NewRandom(cfg.seed)              # record the seed with the results
    kept = []
    FOR i, e IN Enumerate(events):
        IF rng.Uniform() < cfg.drop_prob:
            CONTINUE                       # lost before collection, not delayed
        p = Copy(e)
        p.original_index = i
        # View 1: the claim the host makes. Clock offset only.
        p.event_time = e.event_time + cfg.host_offset[e.host_id]
        # View 2: when the collector hears it. Delay only, from the true time.
        # Fan-in: each record leaves through one worker with its own delays.
        w = rng.Integer(0, cfg.workers - 1)
        p.arrival_time = e.event_time + rng.Draw(cfg.worker_delay[w])
        kept.Append(p)
    # A constant collector clock error shifts every arrival equally:
    # it moves arrival_time, never arrival order.
    by_event_time = StableSort(kept, key = (event_time, original_index))
    by_arrival    = StableSort(kept, key = (arrival_time, original_index))
    RETURN by_event_time, by_arrival

Which view goes to the detector depends on how it ingests. A batch detector that orders by event time reads by_event_time. A streaming detector reads by_arrival in that order, and does its own ordering by event_time with whatever watermark it has, which is exactly what H3 tests. Skew-only runs set every delay to zero. Delay-only runs (H3) set every host offset to zero, so by_event_time is the original order and anything that changes came in through arrival.

Ties are broken by original_index, deliberately. Random tie-breaking adds reordering nobody asked for and shows up as seed variance. Check what else consumes the timestamp, too. KAIROS encodes recorded edge timestamps as features 12, so a skew run changes the features as well as the windows. That's real behavior, not contamination, but say so when you report it.

• Claim: "NTP drift is negligible for forensics under normal load."
  • Check: Measure the offset under stated CPU and I/O load. W32Time supports 1 second, 50ms or 1ms accuracy, each only under its own documented requirements4.
• Claim: "Logs are trustworthy because they are cryptographically signed."
  • Check: Ask what the signature proves. Signed syslog detects tampering and missing messages 8. It doesn't make the producer's clock right, and it doesn't stop delay or reordering.
• Claim: "TCP guarantees in-order delivery, so logs arrive in order."
  • Check: Count the connections. TCP orders bytes within one connection 7. Multi- worker fan-in, per-CPU buffering and clock steps reorder records across them.
• Claim: "My detector uses logical clocks, so it's immune to time drift."
  • Check: Ask where the logical order stops. SLEUTH keeps a per-subject order of events, which lets it store timestamps at millisecond resolution in 16 bits in the typical case 13. Order within a subject isn't order across hosts.

• Attacker capability: We don't know whether an unprivileged attacker can induce the collector delays we'd measure. Real threat models describe attackers pacing activity across windows, not manipulating log delivery, and injecting delay may need privileges the attacker doesn't have.
• Commercial stacks: This plan tests an open-source detector (KAIROS) and standard collectors. Commercial pipelines buffer differently, and the results may not carry over without their configuration data.
• SLEUTH availability: We didn't find a public, runnable SLEUTH artifact. Testing it would mean reimplementing it, with all the verification risk that brings 13.
• Dataset limits: OpTC is a static archive from a single two-week evaluation 3. Offline perturbation is a proxy for live timing, and it can't recreate behavior the archive never recorded.
• Reproduction risk: KAIROS's reported results haven't always reproduced: ORTHRUS reports zero node-level true positives for it on two DARPA E5 datasets 11. Hence the baseline gate.
• Compute: ORTHRUS reports KAIROS using between 2.26 GB and 23.85 GB of GPU memory across the three DARPA E5 datasets 11. OpTC wasn't one of them, so measure before you budget.

This is licensed CC BY-NC so that someone else can run it. If you do, these are the measurements we'd most like emailed to us:

• Collector latency distributions under stated load profiles: Sysmon through WEF, auditd through rsyslog, with the load written down.
• KAIROS's seed variance on OpTC at zero perturbation. The baseline gate needs it, and it's useful even if nothing else gets run.
• Whether anyone can get SLEUTH to run, from any artifact, on any DARPA dataset.
• Any chain-level verdict that flips without a window crossing. One clean example is worth a page of argument.