# Security from Zero — Topic 05 workbook

Lesson: https://secopsnomad.si/blog/security-from-zero-05-accounts-authentication-access/
Practice file: https://secopsnomad.si/downloads/security-from-zero-topic-05-lab.json

Goal: distinguish identification, authentication, authorisation and sessions; evaluate ten requests; write an evidence-led account/session triage note.

Everything in the practice file is fictional. It is not a vendor export, real incident or production policy engine. Work offline; do not enter real passwords, OTP seeds, cookies, bearer tokens, recovery codes or personal identifiers here.

## 1. Set your scope

Study date:
Practice file name and where you saved the unchanged original:
Which time zone is used?
Which exercise are you doing: Lab A (policy) or Lab B (events)?
Why must you not assume Lab B completely replays Lab A's policy?

Explain each in one sentence:
- Identity / account:
- Identification:
- Authentication:
- Authorisation:
- Session:
- Role / group:

Complete: a successful sign-in proves ______, but does not prove ______.

## 2. MFA and passkeys

| Example | Factor categories / important limit |
| --- | --- |
| Password plus security question | |
| Password plus TOTP | |
| Security key with a required local activation PIN | |
| A push notification arriving unexpectedly | |

What does the service store in a simplified passkey registration?
What does the authenticator manage?
What does the service verify at sign-in?
Why is a fingerprint or local PIN not sent as the site's password?
Why might a passkey be device-bound or synced?
Name two risks a passkey does not remove:
How would you verify recovery is available before changing a personal account?

## 3. Lab A: follow the policy

Rules: enabled account; matching permitted channel; group roles plus active temporary roles; exact action and scope; self-profile ownership must match. Grants are additive, without explicit denies or nested groups. Expiry is end-exclusive. These are this teaching model's rules only.

| Request | Active roles / channel / relevant time | Allow or deny? | Decisive rule |
| --- | --- | --- | --- |
| R1 | | | |
| R2 | | | |
| R3 | | | |
| R4 | | | |
| R5 | | | |
| R6 | | | |
| R7 | | | |
| R8 | | | |
| R9 | | | |
| R10 | | | |

Total allow / deny:
Why does R3 differ from R2?
Why does the word admin not settle R5?
What risk exists if an identity administrator can change future role assignments?
Why do R7 and R8 differ even though the action is the same?
What does R9 teach about object ownership?

## 4. Lab B: read the evidence

Copy the user report as a report, not a finding of compromise:
Account ID / session reference (not a credential):
Event date and time zone:
Sources present / important missing sources:

| Reference | UTC | Source | Recorded action / outcome | Fact, interpretation or missing evidence? |
| --- | --- | --- | --- | --- |
| E01 | | | | |
| E02 | | | | |
| E03 | | | | |
| E04 | | | | |
| E05 | | | | |
| E06 | | | | |
| E07 | | | | |
| E08 | | | | |
| E09 | | | | |
| E10 | | | | |

Sign-in records: count / outcomes / recorded method:
Application-audit records: count / successes / denials:
Successful reads after the password reset, by reference:
Successful reads after the revocation request, by reference:
Does an export start prove completion or volume?
Does one denial prove every application session is contained?
Two plausible explanations for an IP change:
Which observations make escalation appropriate without proving compromise?

## 5. One-page handoff

Question and scope:
Observed facts (include E references and UTC times):
Interpretation, explicitly labelled:
What remains unknown:
Next evidence to request, and why:
Who is authorised to make containment changes:
How to verify their effect at the relevant resources:
Disposition and reason:

Do not call the account safe just because a password reset succeeded. Do not call data stolen just because export.start succeeded.

## 6. Lifecycle checklist

Join: owner, approval, role, authentication, recovery and expiry:
Move: old access to remove, not just new access to add:
Leave: identity, application sessions, delegated grants and workload ownership:
Recover: approved verification channel, method changes, session checks:
What local whoami / id output can show, and which cloud permissions it cannot show:
Optional local check completed? Do not include real output in a public portfolio.

## Answer key — check after completing your own work

Lab A: R1 allow; R2 allow; R3 deny; R4 deny; R5 deny; R6 allow; R7 allow; R8 deny; R9 deny; R10 allow. Five allow, five deny.

R3 is exactly at expiry, 2026-10-27T09:15:00Z. R5 has no invoice-read grant. R8 uses the wrong channel. R9 requests another account's profile despite a self-only grant. Administrative ability to change future assignments remains powerful, although this static exercise does not simulate it.

Lab B: E01 and E04 are the two sign-in records: one success (password+totp), one denial. E02, E05, E07, E09 and E10 are application-audit records: four successes and one denial. E07 and E09 follow the successful password reset at E06; E09 also follows the accepted revocation request at E08. E04 did not stop the existing session's E05. E10 is one application rejection, not evidence about all other sessions. E05 gives no completion or volume.

Escalate the unexpected prompt, recovery-method change and export context through the team's process; preserve the evidence and verify expected activity. Who acted, whether the export completed, and the wider session state remain unknown. IP examples are documentation addresses and must not be blocked or queried as threat indicators.

Portfolio statement: evaluated a fictional role-and-scope policy, reconciled identity/application observations and explained session-containment limits. Claim real administration or investigation experience only when you actually have it.