Chapter 12 — Evidence flows across identity, endpoint and cloud | Technologist 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 12 — Evidence flows across identity, endpoint and cloud

Lesson map

Lesson 12 published. Map, example, EX034.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["12.1 Why flows, not just logs"]
  N2["12.2 Three flow families"]
  N3["12.3 Integrity and access"]
  N4["12.4 Verifying a flow"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX034"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["12.1 Why flows, not just logs"]
  N2["12.2 Three flow families"]
  N3["12.3 Integrity and access"]
  N4["12.4 Verifying a flow"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX034"]

[Learning outcomes and connection]
    |
    v
[12.1 Why flows, not just logs]
    |
    v
[12.2 Three flow families]
    |
    v
[12.3 Integrity and access]
    |
    v
[12.4 Verifying a flow]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX034]

Learning outcomes and connection

You will be able to (1) design the collection path for identity, endpoint and cloud evidence into a central store; (2) set retention and integrity controls on each flow; and (3) verify that a flow actually delivers what an investigation will need. Chapter 11 told you what exists; this chapter makes sure its evidence arrives somewhere safe before an incident.

12.1 Why flows, not just logs

A log that exists only on the source system is fragile: it rotates, it can be altered by an intruder, and it is unavailable if the system is down. An evidence flow moves records from source to a central store with known latency, retention, access control and integrity protection. NIST SP 800-92 recommends centralized log management with protected storage and planned retention. The appointment service's local-only logs with seven-day rotation were a fragile source of exactly this kind, and forwarding them was one of the first changes.

12.2 Three flow families

Identity: sign-in and audit logs via the provider's export or API to the central store; include non-interactive sign-ins and administrative actions. Endpoint: agent telemetry (processes, network, file events) and operating-system logs; plus on-demand collection capability for memory and files. Cloud: control-plane audit logs (who changed what), data-plane logs where enabled (object reads, database queries) and network flow logs. For each flow record the fields received, the delay, the cost and the retention. Fernmoor's flow matrix records exactly this, flow by flow, and adds a canary test for each.

12.3 Integrity and access

Write central logs to storage the source administrators cannot alter (separate account or tenant, write-once or object-lock features where available). Restrict read access to the response and audit functions and log access to the logs. Hash exported evidence sets (FIPS 180-4 SHA-256) when they leave the store for a case. In the missing data-read logs case, the control-plane logs survived because they were in a separate account, so the new access key for svc-reports could be dated. The flow matrix keeps the same separation for data-read logs, so an intruder with administrative rights in the production account cannot delete the record of what they read.

12.4 Verifying a flow

A flow is verified when a known test event appears in the central store with correct fields and timestamp within the expected delay. Do this at onboarding and periodically ("canary" events), because flows silently break when credentials expire or formats change. Fernmoor's canaries are listed in its flow matrix: a weekly test sign-in for identity, a harmless EICAR test file for endpoint, a tag change on a test bucket for the control plane, and a read of a canary object for data reads. In the capstone, a deliberately disabled identity canary alerted within the 30-minute limit.

12.5 Worked example (synthetic): the missing data-read logs

Fictional. During a permit-data case, the team asked: did anyone download the permits-archive storage bucket? Control-plane logs showed a new access key created for svc-reports at 14:05; but object-read logging had never been enabled, so no record could show which objects were read. The case concluded "unable to determine", which forced a cautious privacy assessment. Afterwards the team built a flow matrix:

Flow	Source	Fields checked	Delay	Retention	Immutability	Canary
IdP sign-ins	IdP API	user, app, src, result, MFA	5 min	400 days	object lock	weekly test sign-in
Endpoint	agent	process, parent, hash, user	2 min	90 days hot	vendor-managed	EICAR test file
Cloud control plane	audit log	principal, action, resource	15 min	400 days	separate account	tag change on test bucket
Cloud data reads	object access logs	principal, object, bytes	60 min	180 days	separate account	read of canary object

The data-read flow was enabled for buckets holding personal data, with its storage cost approved by the data owner.

12.6 Common errors and limits

Assuming default logging captures data access.
Storing logs where an attacker with admin rights can delete them.
Never testing flows after onboarding.
Retention shorter than typical detection delay; intrusions are often found weeks later.

The missing data-read logs case is the first error in practice: the team assumed storage logging covered reads, and when it did not, the case closed as unable to determine. Separate-account storage protects against the second, scheduled canaries against the third, and retention of 180 to 400 days in the flow matrix against the fourth.

Exercises — chapter 12

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.

EX034 — Flow card. Steps: complete a flow card for file-server audit logs. Rubric: 3 = source, fields, delay, retention with rationale, immutability, access, canary test; 2 = missing two; 1 = partial; 0 = none.

EX035 — Canary design. Steps: design canary tests for identity and cloud control-plane flows and an alert if they fail. Rubric: 3 = specific test events, schedule, expected appearance window, alert route and owner; 2 = no alert; 1 = vague; 0 = none.

EX036 — Unable to determine. Steps: write the case-record paragraph for the missing data-read logs case, explaining what could and could not be established. Rubric: 3 = facts (key creation, time, principal), gap (no object-read logs), consequence for assessment, remediation; 2 = missing consequence; 1 = speculative; 0 = none.

Chapter synthesis

Build evidence flows, not isolated logs: central, timely, retained long enough, protected from source administrators and verified by canaries. When a flow is missing, say "unable to determine" plainly and fix the flow.

Continue studying — chapter 12 of 30

← Chapter 11 · Course chapter index · Chapter 13 →

Continue to the next authored lesson.