skip to content

Which date starts the dwell clock when the first malicious action predates every surviving log record?

level: middleimportance: must knowfreq 58%

answer

  1. three dates, three different claims
  2. code cannot run before it is installed
  3. retention bounds visibility, not history
  4. publish a floor as a floor
  5. evidenced or estimated, flagged per date

basics

~20 s

Anchor on the earliest date the malicious code could have acted — a deployment or change record often survives when host telemetry has rotated. Retention gives a floor on dwell, never the start date, and every published span must carry the source that anchored it.

solid answer

~50 s

You have three dates and they are not interchangeable. Take a monitoring agent whose vendor shipped a signed update carrying malicious code to a Linux server fleet. The configuration-management deployment log says that build landed on 9 January. The oldest surviving `auditd` execve record for the fleet is 22 January, because the audit trail rotates at 30 days. The detection rule fired on 20 February. The honest anchor is 9 January: the code could not have acted before it was installed, so that record bounds the start from below and gives a defensible 42-day dwell. The 22 January date only gives you a floor — 29 days you can prove from telemetry — and publishing it would report your retention policy as the intruder's lifetime. Whatever you publish, record which source anchored it and whether the date is evidenced or estimated, because that flag is what lets the number be revised later.

code

json · 15 lines
json
{
  "case": "SOC-2418",
  "clock_start_candidates": [
    { "date": "2026-01-09", "event": "malicious agent build deployed to fleet",
      "source": "config-management deployment log", "basis": "earliest possible malicious action" },
    { "date": "2026-01-22", "event": "agent process spawns /bin/sh",
      "source": "auditd execve (30-day retention boundary)", "basis": "earliest surviving evidence" },
    { "date": "2026-02-20", "event": "detection rule fires on agent-spawned shell",
      "source": "SIEM alert", "basis": "first alert" }
  ],
  "anchor_used": "config-management deployment log",
  "dwell_days": 42,
  "telemetry_only_floor_days": 29,
  "start_date_quality": "estimated"
}

go deeper

for a junior

Know that the dwell clock starts at the adversary's first action, and that a log record only proves what it recorded — its absence proves nothing about what happened before your retention window.

for a middle

Be ready to reason across sources: which record bounds the start from below, why a deployment or change entry can outlive host telemetry, and how to state a span you can only bound rather than measure.

for a senior

Demonstrate the case discipline — every date carries its source and an evidenced-or-estimated flag — because that is what allows a published span to be revised later without the revision looking like an error.

for a principal

Own the standard that says censored spans are published as bounds. The bias in publishing floors as measurements is systematic and flattering, and only a written rule stops it accumulating across a whole reporting year.

## Three dates, three different claims The scenario that makes this concrete: a vendor of a monitoring agent ships a *signed* update containing malicious code to your Linux server fleet. Nobody notices for weeks. When you finally build the case, three dates present themselves, and each supports a different claim. | Date | Source | What it actually proves | |---|---|---| | 9 Jan | configuration-management deployment log | the malicious build was present on the fleet from this date — the code cannot have acted earlier | | 22 Jan | oldest surviving `auditd` execve record | you can *prove* execution from here forward; older records rotated away | | 20 Feb | the detection rule firing in the SIEM | a rule matched and a human looked | Dwell is detection minus start. Anchor on 9 January and you publish **42 days**. Anchor on 22 January and you publish **29 days**. Anchor on the alert and you publish nothing meaningful at all. ## Why the deployment record is the right anchor The direction of the claim is everything here. A deployment record says *this version of this package was installed on these hosts on this date*. Malicious code inside that package cannot have executed before the package existed on the host, so the deployment date is a lower bound on the first malicious action — which makes it an upper bound on the true dwell being *shorter*, and the most defensible start you have. Combined with the fact that an agent of this kind runs continuously from install, the estimate is strong: the first malicious action is somewhere between 9 January and the earliest execution you can still prove, and probably close to the former. The surviving `auditd` record supports a much weaker claim. `auditd` records syscalls according to configured rules, and `execve` is the execution one; its records tell you a process ran at a time. Their *absence* before 22 January proves nothing whatsoever: it is equally consistent with the records having rotated, the audit rule not having been configured at the time, the host not having been onboarded, or the adversary having tampered with the trail. Absence of a record is never evidence of absence of activity, and a candidate who slides from 'no record' to 'no activity' has made the characteristic error of this whole domain. ## The floor, and how to say it out loud When the deployment log has *also* rotated and you have no anchor at all, you do not simply fall back to the earliest surviving evidence and publish it as a clean number. You publish it as a bound: **'at least 29 days; true start unknown, earliest evidence 22 January'**. That phrasing carries the one thing the bare number destroys — that the figure is censored by your own retention and can only move upward with better evidence. A SOC that publishes floors as if they were measurements will always look better than it is, and the bias is systematic rather than random: it never errs in the pessimistic direction. ## What the record for each case must carry Every closed case should record, per date: the timestamp, the *source* that produced it, and a flag for **evidenced** versus **estimated**. That third field is what makes the whole metric revisable. When someone later finds an older artefact — an archived build manifest, a colder tier of logs, a vendor's own disclosure of when the malicious build was published — you can move the start date, recompute the case's dwell, and explain exactly which claim changed. Without it, the number is unauditable and every revision looks like an error. ## Adjacent traps Two things this question is *not*. It is not the reconstruction of the intrusion itself — which hosts, which accounts, how the adversary moved — that is a different exercise, and here the telemetry is being used for one narrow purpose: to place clock-start events on a line. And the vendor's own published compromise date is not automatically your start date; dwell is measured per estate, so what matters is when the malicious build reached *your* fleet, which may be days or weeks after the vendor's. ## The interview signal What is being tested is whether you will state a number you cannot defend. The strong answer names the anchor, names its source, states the direction the estimate can move, and refuses to let retention masquerade as history.

  • The deployment log had also rotated and you have no anchor at all. What do you publish?
    A bound, stated as one: 'at least 29 days, true start unknown, earliest evidence 22 January'. You never launder a floor into a clean figure, because the censoring is systematic — it can only ever make you look better. Flag the case's start-date quality as unevidenced so the aggregate can be recomputed if an older artefact turns up later.
  • The vendor publishes that the malicious build was available from 2 January. Does your dwell change?
    Not automatically. Dwell is measured per estate, so what matters is when that build reached your fleet, not when the vendor released it. If your deployment record still says 9 January, the anchor stands. The vendor's date is useful only as a sanity check that your record is not itself missing an earlier rollout.
  • Why is the absence of execve records before the retention boundary not evidence that nothing ran?
    Because at least four explanations fit equally: the records rotated, the audit rule was not configured then, the host was not yet onboarded, or the trail was tampered with. Absence of a record is a statement about your collection, not about the estate. Treating it as proof of a quiet period is the most common wrong answer in this domain.

saying these in an interview costs you the question

  • Uses the oldest surviving record as the intrusion's start
  • Assumes no log record means no activity
  • Publishes a censored floor as a precise dwell figure
  • Anchors on the alert because the start is uncertain
  • Adopts the vendor's disclosure date as the estate's start
  • Records a start date with no source attached

context

resolving links…