Given VPN concentrator logs and CI runner job logs, how do you date an intrusion's spread?

## The artefact you are producing Not a narrative. A **dated entity picture**: one row per entity — host, account, credential, service — with, for each, the earliest observed adversarial activity, the latest, how the entity came to be involved, what it reached next, and a citation to the record supporting every one of those cells. This table is what containment scope, credential resets and every later statement about the intrusion are derived from, and it will be re-read months later by people who were not in the room. Normalise timestamps to a single zone before you join anything. Mixed local times silently reorder a timeline. ## Pivots that actually survive Across a VPN concentrator and a build estate, the durable pivots are: - the **client certificate subject and serial** presented at session establishment; - the **address the concentrator assigned** to that session, bounded by the session start and stop; - the **token or service-account identity** a job ran under, and the **job id**; - the **git ref and commit** a job built, and **artefact hashes** it produced or pulled; - **registry and package pull records**, which often live longer than the job logs themselves. ## The join, and the rule that keeps it honest The concentrator says: at 22:41 UTC a session was established for certificate subject `contractor-jlee`, from an external address, and was assigned an internal address. The runner job log says: at 22:53 UTC a job ran on runner `build-07`, its remote address was that same internal address, and it authenticated with a service token. That is a strong link — **inside the lease**. Assigned addresses are recycled, often within the same day. So the rule is: an address is an identity only between the session's start and stop timestamps, and every join must be constrained by that window. Where a lease boundary is ambiguous, downgrade the link to inferred and go looking for a second, independent pivot such as the certificate serial or a shared artefact hash. ## What each source cannot tell you - **Concentrator records** show sessions: established, duration, bytes if you are lucky. They do not show what moved inside the tunnel. Bytes moved is not what the bytes were. - **Job logs** show what the job definition ran and what its steps wrote to standard output. A step that was tampered with can do work that never appears there, and log output can be suppressed by the step itself. - **Runner workspaces** are ephemeral by design and are wiped or reused between jobs. Absence of dropped files on a runner is not evidence that nothing was dropped; it is evidence that you looked too late. - **Token identity is a service account**, not a person. `svc-release` in a job log identifies the credential used, and a human name attached to it in some inventory is an inference, not an observation. ## Observed versus inferred Keep them visually distinct in the same table. An observed cell has a record behind it. An inferred cell has reasoning behind it and names the evidence that is missing. Anyone reading the picture, including counsel, must be able to strip the inferences out and still have a coherent, defensible core. Mixing the two is how an investigation ends up asserting things nobody can support. ## Both frontiers, and when to stop The picture grows in two directions: backwards toward first foothold and forwards through spread. An entity enters when there is evidence tying it to adversary-controlled activity, and it carries a note of *why* you believe that activity was adversary-driven rather than routine — build estates are full of automation that looks alarming out of context. A workable stopping rule for an entity: its inbound and outbound activity across the relevant window is accounted for, either as adversary activity you have dated or as routine activity you have explained. Unaccounted activity keeps the entity open. 'No alerts on it' is not an account of its activity. ## Keeping it usable Version the picture and date each revision. Facts change: a link is downgraded, a host is cleared, an entity is added a week later. If the table is edited in place with no history, two people quoting it a month apart will quote different things, and neither will know why.