Triage Separates Facts, Hypotheses, and Urgency

Incident response begins before you know the full story.

That makes language discipline critical.

Start with facts

Fictional alert:

16:04 alert=privileged-role-change account=alice old=viewer new=admin approver=missing

Correlated evidence:

16:03 login alice success training-mfa
16:04 role_change alice viewer→admin approver=missing
16:05 admin_action alice action=export-config result=success
16:05 helpdesk note: coach says no role change was planned

Facts from the supplied dataset:

• the fictional system recorded the role change;
• approval field is missing;
• a later privileged action is recorded;
• coach reports no planned change.

Hypothesis:

The role change may be unauthorized or may reflect a broken approval workflow.

Do not write:

Alice was hacked.

The evidence does not establish that mechanism.

Triage asks impact and scope questions

Useful questions:

• which asset/function is affected?
• what privilege changed?
• what actions occurred after the change?
• is the condition ongoing?
• what evidence sources are healthy?
• which other identities/systems show similar events?
• what required functions would be affected by containment?
• who has authority to approve containment?

This is system scoping, not threat hunting theater.

Severity can change as evidence changes

Initial condition:

unexpected role change, no privileged actions

Later evidence:

privileged configuration export occurred

The incident may deserve higher urgency because the potential impact expanded.

Triage is iterative.

Preserve evidence before changing too much

A defensive team may want to capture:

• relevant logs;
• configuration state;
• role/session state;
• process/service state;
• timestamps/time synchronization;
• change records;
• known-good reference information.

In this course, all evidence is supplied/synthetic or comes from your own disposable environment.

Do not collect real student/private data for an assignment.

Evidence preservation needs provenance

Record:

source
collection time
collector/operator
query/filter
original path/system
hash if appropriate for static exported files
transformation/normalization

Week 3 hashes can support export-integrity records, but remember what a hash proves: byte equality, not truth.

Build an incident statement

A strong initial statement:

At 16:04, the fictional identity system recorded Alice changing from viewer to admin without the expected approval field. At 16:05, the application recorded a successful privileged configuration-export action for the same account. The coach reports no planned role change. The current mechanism and actor are not established; immediate priorities are to preserve identity/session/change evidence, confirm the current role/session state, and evaluate containment that prevents further privileged actions while preserving required status service functions.

That is specific without pretending certainty.

Activity: facts vs hypotheses

Classify:

1. role_change old=viewer new=admin — fact in supplied log.
2. role change was malicious — hypothesis.
3. approval field is missing — fact in supplied record.
4. attacker stole Alice's password — unsupported hypothesis.
5. privileged export occurred after role change — fact in supplied timeline.
6. export contained secrets — unknown unless evidence describes contents.

Build a triage table

Fact
Source
Confidence/limitation
Hypothesis it supports
Evidence needed next
Urgency effect

Include at least six facts.

Begin the Incident Decision and Recovery Record

Add:

1. initial incident statement;
2. required functions/assets potentially affected;
3. facts vs hypotheses;
4. evidence preservation plan;
5. current uncertainty;
6. decision authority; and
7. two possible containment options.

Lesson 2 compares containment choices.