Scope an incident from incomplete audit evidence

Incident scoping begins with what the evidence can establish. Identify the credential or actor, its authority, the observed actions and the time coverage. Keep a timeline with confidence labels. A suspicious action can justify containment before every detail is known, but the final scope should not exceed the evidence without a clear inference label.

Distinguish access from exfiltration. A successful read can establish that data was returned to a caller under the logged operation. It may not prove how much the caller retained or shared. A failed request may still reveal metadata or produce a partial side effect, depending on the system. Read the action semantics rather than rely on a generic success flag.

Authority can expand during the incident. A token that changes a role policy may create a path that remains after token revocation. Review administrative changes and derived credentials within the relevant scope. Rotating the original key is containment for that key, not proof that all access paths ended.

Preserve evidence without spreading sensitive values. Use credential IDs, object IDs, hashes and controlled log links. Record collection limits, clock uncertainty and retention gaps. A screenshot without query filters or time range is weak evidence for a durable conclusion.

An interview answer should produce a bounded statement and a next-evidence plan. Avoid both extremes: declaring total compromise from one unexplained event or declaring safety because the available logs look quiet.

Teaching incident concerns service credential K9. It can read invoices for tenant red and update one export-storage policy. Available audit logs cover 12:00–14:00. A public exposure may have begun at 11:30, but the exact first publication time is uncertain. K9 is revoked at 13:10.

Confirmed facts include successful reads of I1 and I3 and a policy update. The record does not establish that every red invoice was read. It also does not establish that nothing happened between 11:30 and 12:00. The policy update is a priority because it may have changed access beyond K9's own lifetime.

Suppose P1 changed from private export access to a broader principal set. The incident scope now includes objects reachable through that policy, subject to actual storage logs and configuration semantics. Revoke K9 and restore the approved policy through the incident process, while preserving the diff and relevant metadata. Do not wait for a perfect exfiltration count before removing an observed unauthorized grant.

If the policy diff instead changes a harmless description field, it may not widen access. The successful update event alone did not prove privilege expansion. Inspect the changed fields. This is why a good scoping answer separates the observed administrative action from the inferred impact.

A bounded internal statement can read: 'Available logs show K9 successfully read I1 and I3 and changed policy P1 between 12:05 and 12:20. K9 was revoked at 13:10 and a later use was denied. The policy's access impact is under review. Logs before 12:00 are unavailable, so activity in the earlier possible exposure interval is unknown.'

That statement is useful because each sentence has a source or an explicit limit. It does not minimize the incident. It allows the team to contain the known path while identifying the next evidence needed. The exact user or legal notification process is outside this teaching exercise and must follow the organization's authorized response procedure.

First, obtain the policy diff and confirm whether it created another access path. Second, enumerate objects that the changed policy could expose and inspect access logs for that scope. Third, verify whether K9 could mint credentials or modify other identities. Fourth, check the legitimate owner's expected activity to distinguish known automation from unexplained actions. Preserve source timestamps and query parameters.

A legitimate deployment explanation should be verified through trusted run records. A caller-supplied run_id could be forged or copied. Correlate the CI or job record, artifact and expected resource changes. If the event lacks a run identity, that is a gap, not automatic proof of an attacker.

Clock alignment matters. If the storage system is two minutes behind the identity provider, a read that appears after revocation may actually precede it. Check time synchronization and timestamp semantics before declaring revocation failure. Conversely, a provider may have propagation behavior that requires verification. Record what the rejection test actually demonstrates.

The interview should close with containment status, confirmed scope, unknown scope and the next decision. This structure helps a responder work under pressure without turning every hypothesis into a fact. It also makes a later review able to see why the team acted when it did.

Teaching calculation: logs cover 120 minutes, while the earliest possible exposure is thirty minutes before log coverage begins and revocation occurs seventy minutes into coverage. The potentially valid exposure interval could be 100 minutes, of which the first thirty lack these logs. This is not a probability of misuse. It is a coverage gap. The available successful reads establish at least the logged actions, not a maximum possible count for the full interval.

A token is revoked at 15:00. A storage log shows a read at 15:01, but that log's clock is known to be two minutes ahead. What can you conclude, and what additional evidence would test whether revocation failed?

The timestamp could correspond to 14:59 in the identity provider's time, before revocation. It does not by itself prove post-revocation use. Align clocks and timestamp semantics, inspect request identity and perform a controlled safe rejection check through the provider's supported method. Also review whether another credential or widened policy authorized the read. Do not silently discard the event; record the uncertainty and resolution.

Score out of four: one point for the correct result, one for showing the intermediate reasoning, one for identifying the stated failure case, and one for a verification that could disprove the answer. Do not award the reasoning point for a tool name alone.

Misconception 1: one successful read proves every object was stolen. Scope must follow observed actions and reachable authority. Misconception 2: revoking the original token removes every persistent change. A policy or derived credential created earlier can remain active.

Evidence class: recommended. Original practice.

What would you report after finding two successful reads and one unexplained policy change?

Strong answer: I would report those confirmed actions, the credential's scope, containment status and log coverage limits. I would prioritize the policy diff and any derived access, while avoiding an unsupported total data-loss claim.

Follow-up: How would you validate a legitimate-job explanation without trusting a caller-supplied run label?

Weak answer indicators: Equating no logs with no activity; treating timestamps from different systems as perfectly aligned; ignoring persistent policy changes.

Technical references: OWASP secrets management; OWASP logging. Sources support the documented mechanisms. The numbers, decisions, rubrics and interview prompts in this lesson are original teaching examples, not measurements or employer question claims.