Chapter 22 — Evidence provenance and service dependencies | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 22 — Evidence provenance and service dependencies

Lesson map

Lesson 22 published. Map, example, EX064.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["22.1 The provenance map"]
  N2["22.2 Source attributes"]
  N3["22.3 Dependencies between sources"]
  N4["22.4 Weak links"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX064"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["22.1 The provenance map"]
  N2["22.2 Source attributes"]
  N3["22.3 Dependencies between sources"]
  N4["22.4 Weak links"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]

[Learning outcomes and connection]
    |
    v
[22.1 The provenance map]
    |
    v
[22.2 Source attributes]
    |
    v
[22.3 Dependencies between sources]
    |
    v
[22.4 Weak links]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX064]

Learning outcomes and connection

You will be able to (1) build a provenance map from source systems through transformations to conclusions; (2) record retention and integrity for each source; (3) identify where a missing dependency weakens a conclusion; and (4) state the conclusion with its evidential limits. Chapters 2, 15 and 17 prepared the ingredients; here they are combined for a real investigative question. Chapter 25 applies this map in a laboratory timeline.

22.1 The provenance map

A provenance map is a diagram with three layers: sources (systems that recorded something), transformations (exports, parsers, joins, enrichment) and claims (statements in the report). Each claim points back to the transformations and sources that support it. The map makes it visible when a claim rests on one source only, or on a transformation nobody can reproduce.

In the fin-04 example, the claim "outside party" points back to the IdP sign-in through geolocation enrichment, to the help-desk ticket and to the mail audit; the map shows at once that the location part rests on enrichment of unknown version.

22.2 Source attributes

For each source record: owner, what it records, clock and time zone, retention period, who can modify it, export method, and known gaps. A help-desk ticket system, for example, records what callers said, entered by an agent, with the agent's clock and typing delay.

In the fin-04 case, these attributes changed the investigation: the IdP's retention had dropped to 30 days when the premium licence lapsed on 1 March, the endpoint agent recorded nothing from 9 to 11 March, and the help-desk ticket was in local time with an assumed offset.

22.3 Dependencies between sources

Sources depend on infrastructure: a cloud audit log depends on the tenant's licence tier and settings; a host log depends on the agent running; enrichment (geolocation of addresses) depends on a third-party database version. If a dependency failed or changed, the source's silence or content changes meaning.

For fin-04, the IdP log's retention depended on a licence that lapsed on 1 March, and the laptop's telemetry depended on an agent that was offline from 9 to 11 March. Neither change was an attack, but both altered what the sources could show for 10 March.

22.4 Weak links

A conclusion is only as strong as its weakest required link. Look for: single-source claims, transformations with undocumented assumptions (time-zone defaults, geolocation), sources outside retention, and dependencies whose health in the window is unknown.

In the fin-04 case, the weakest link for "outside party" is geolocation from an enrichment database of unknown version, so the report states the location as unverified. The stronger links, the forwarding rule eight minutes after sign-in and the user's account of an unsolicited call, carry the conclusion instead. Rewording a claim to rest on its strongest links is often better than dropping it.

22.5 Worked example (synthetic): a possible account takeover

Fictional. Claim under consideration: "The account fin-04 was taken over by an outside party on 10 March."

Sources: - S1 Cloud IdP sign-ins: 10 March 07:12 UTC sign-in for fin-04 from an address geolocated to another country, MFA satisfied by phone call. Retention 30 days (premium licence lapsed on 1 March; previously 90). - S2 Endpoint agent on fin-04's laptop: no events 9–11 March (agent offline). - S3 Help-desk ticket: 10 March 09:30 local time, "user says she did not sign in and got a strange call asking to approve". - S4 Mail audit: an inbox forwarding rule created 07:20 UTC.

Transformations: T1 geolocation enrichment of S1 address (database version unknown); T2 time-zone normalization of S3 (agent's local time, UTC−3 assumed).

Map: Claim "outside party" ← S1 via T1 (weak: geolocation version unknown, VPNs common), S3 (user statement, moderate), S4 (rule creation 8 minutes after sign-in, strong behavioural indicator). Claim "not the user from her laptop" ← S2 should help but is silent because the agent was offline — a missing dependency. Strength: the S1–S4 sequence (sign-in, then forwarding rule within 8 minutes, user denies, phone-call MFA approval) makes takeover likely; the location claim is weak.

Report wording: "Likely account takeover: sign-in at 07:12 UTC with MFA approved by phone call (IdP), forwarding rule created at 07:20 (mail audit), user reports an unsolicited approval call (help desk). Origin location unverified (enrichment version unknown). Laptop telemetry unavailable 9–11 March (agent offline), so device involvement cannot be assessed."

22.6 Common errors and limits

Presenting enrichment (geolocation, reputation) as observation.
Ignoring a source's licence- or configuration-dependent retention.
Treating a silent source as negative evidence when its dependency failed.
Provenance maps can become large; keep only the links that support or weaken report claims.
Forgetting to preserve a source whose retention is about to expire, as with the 30-day IdP log in the fin-04 case.
Normalizing help-desk times with an assumed offset and then treating them as precise.
Letting a strong link for one claim lend false strength to a different claim.

Exercises — chapter 22

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX064 — Draw the map. Steps: draw the provenance map for §22.5 and grade each link (strong/moderate/weak) with a reason. Rubric: 3 = all sources, transformations and claims, grades justified; 2 = one missing; 1 = list only; 0 = none.

EX065 — Retention risk. Steps: explain the effect of the lapsed premium licence on this investigation and on future ones. Rubric: 3 = sign-ins older than 30 days may be lost, preventing search for earlier compromise; recommend preservation export now and licence review; 2 = partial; 1 = misses it; 0 = none.

EX066 — Strengthen the weakest link. Steps: propose two bounded checks to improve the location claim or the device claim. Rubric: 3 = compare address with known VPN/corporate egress and IdP risk signals; ask the agent's management console why it was offline and check the laptop's local logs with authorization; 2 = one; 1 = vague; 0 = none.

Chapter synthesis

Map every claim back to its sources and transformations, record each source's dependencies and retention, treat silence from a failed dependency as unknown, and word conclusions to the strength of their weakest required link.

Continue studying — chapter 22 of 40

← Chapter 21 · Course chapter index · Chapter 23 →

Continue to the next authored lesson.