A Zeek-style sensor restarts mid-transfer: what can it no longer say about files an intruder moved inside that partner session?

## Why parsers need the beginning Two mechanisms in a parsing sensor depend on seeing a connection from its first packets. **Protocol identification.** Dynamic protocol detection works by offering the opening bytes of a stream to candidate analyzers until one claims it. Ports are a hint, not the decision. If the sensor starts in the middle, those opening bytes are already gone from the wire and cannot be recovered, so no analyzer claims the stream and none attaches later. **Stream reassembly.** To present an ordered byte stream, the engine tracks sequence numbers from an established baseline. Coming in midstream, it has to infer that baseline from traffic already in flight. Engines can be configured to attempt midstream pickup, and it is often disabled by default precisely because inferring state is unreliable and expensive; even when enabled, the application-layer parse usually cannot be recovered because the protocol's own framing began before the first observed byte. The result is that a session which began before the restart yields a truncated connection record - byte counts from the restart onward, an inferred or missing connection state - and nothing above it. ## What survives on the matching side Byte matching is not immune, but it degrades differently. A rule that searches a raw packet payload for a constant, with no dependency on flow direction, established state or reassembled buffers, will still fire on packets seen after the restart. Rules that require an established flow, or that match inside a reassembled application buffer or a parsed field, will not - the engine has no such state for this session either. So the gap is not "parsing blind, matching fine"; it is "parsing blind, matching reduced to its shallowest form". ## The extranet is where this actually bites On an internal estate the problem is self-healing: sessions are short, so within a minute or two nearly everything the sensor sees is a session it saw begin. An extranet inverts that. Bespoke B2B file transfer and scheduled exchanges hold connections open for hours; some partner integrations keep a long-lived session up permanently and multiplex work inside it. A restart at 02:00 can leave a session opaque until the partner's next scheduled reconnect - which may be tomorrow, and is not yours to schedule. That is the price, and it is the reason this is a design question. Restoring parsing means one of: - **Wait.** Accept a gap of unknown length on exactly the interface where you have the least control. - **Force a reconnect.** Bounce the path or the partner-facing service so sessions re-establish. That is an outage on a business flow with a counterparty, and someone other than you has to agree to it. - **Avoid the restart.** Some engines support handing sockets or state across a reload; failing that, run redundant sensors and stagger their restarts so at least one instance has seen every long-lived session from its start. The third is the answer an interviewer is listening for, because it is the one that makes the cost a design decision instead of an incident. ## What this means for an investigation An investigator asked what a partner session carried during that window must not read the absence of file records as an absence of files. The correct claim is bounded: *for sessions that began before 02:14 and were still open, we have byte counts and nothing else; for sessions that began after 02:14, we have full records.* That is a defensible statement. "No files were transferred" is not - it confuses a gap in collection with a fact about the estate, which is the single most common way this failure is misreported. ## Operational practice Emit a restart marker into the same log stream that carries the session records, so the gap is discoverable later without archaeology. On restart, enumerate the flows still open on the partner-facing interface - the switch or the endpoints can tell you, even when the sensor cannot - and record that list as the known-degraded set. Alarm if the count of parsed sessions on that interface stays at zero for longer than the expected reconnect interval, because a long-lived session that never restarts turns a short restart into an indefinite blind spot that nothing else will report.