Chapter 7 — Identity and access foundations
Lesson map
Lesson 07 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes and connection"]
N1["7.1 Authentication, authorization and sessions"]
N2["7.2 Types of identity"]
N3["7.3 Containing an account compromise"]
N4["7.4 Logs to retain"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["7.1 Authentication, authorization and sessions"]
N2["7.2 Types of identity"]
N3["7.3 Containing an account compromise"]
N4["7.4 Logs to retain"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX019"]
[Learning outcomes and connection]
|
v
[7.1 Authentication, authorization and sessions]
|
v
[7.2 Types of identity]
|
v
[7.3 Containing an account compromise]
|
v
[7.4 Logs to retain]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes and connection
You will be able to (1) explain authentication, authorization, sessions and tokens as a responder needs them; (2) list identity actions that contain an account compromise and the order in which to perform them; and (3) identify the identity logs that must be retained. Identity appeared in every earlier example; most of Fernmoor's real cases will be identity cases.
7.1 Authentication, authorization and sessions
Authentication proves who is acting (password, authenticator, certificate). Authorization decides what they may do (roles, groups, policies). After sign-in, a session or token represents the authenticated identity; refresh tokens can extend access for days without a new password. NIST SP 800-63B describes authenticator types and their assurance; phishing-resistant authenticators (such as FIDO2 security keys) resist the credential-relay attacks that defeat one-time codes and push approvals. In the night-time MFA case, the attacker relied on push approval: the clerk tapped approve to stop the buzzing, and a new authenticator was registered two minutes later.
7.2 Types of identity
Human accounts, privileged administrator accounts, service accounts (used by software), and external identities (suppliers, residents). Service accounts are frequently over-privileged, never rotated and unmonitored — Chapter 1's svc-patch is typical. At Fernmoor, each type has its own owner: the Identity team for staff and administrators, the service owner for each service account, and Procurement for supplier identities. A response action against a service account therefore needs the service owner's view of what will stop working. External identities such as supplier accounts appear in later chapters as the route for both the upload workflow and the Quiet Meter exercise.
7.3 Containing an account compromise
Order matters. If you reset the password first but leave sessions and authentication methods, an attacker with a valid refresh token or a newly registered MFA device keeps access. A typical sequence: (1) preserve identity logs for the account; (2) revoke sessions and refresh tokens; (3) remove attacker-added authentication methods and application consents; (4) reset the credential; (5) check for mailbox rules, forwarding and API keys created by the account; (6) monitor for re-entry. For privileged accounts, also review what they changed. The night-time MFA case at Fernmoor followed this order, ending with a mailbox rule search.
7.4 Logs to retain
Sign-in logs (interactive and non-interactive), audit logs (role changes, method changes, consents), and application access logs. Default retention in many identity platforms is short; extend it or export centrally. CISA's federal playbooks list identity and credential review among standard response steps. In the night-time MFA case, the analyst exported 30 days of sign-in and audit logs before revoking anything. That export preserved the approved push at 02:12 and the new authenticator at 02:14, which the platform's default retention might have lost within weeks. Fernmoor's evidence flows now forward these logs centrally with longer retention.
7.5 Worked example (synthetic): an MFA method added at night
Fictional. At 02:14 Fernmoor's IdP audit log records a new authenticator app registered for permits-clerk-4, from 198.51.100.23, after an approved push at 02:12. The clerk was asleep and says she tapped "approve" on a notification to stop it buzzing. The duty analyst follows the identity runbook: exports 30 days of sign-in and audit logs (hashed), revokes sessions, deletes the new authenticator, resets the password with identity verification by her manager, and searches for mailbox rules — finding a rule forwarding messages containing "invoice" to an external address, which is removed and preserved as evidence. A follow-up change, owned by the Identity team, enables number-matching for push approvals and schedules security keys for permit staff.
7.6 Common errors and limits
- Password reset alone, leaving sessions and methods intact.
- Forgetting non-interactive sign-ins and service principals.
- Destroying the attacker's artefacts (mailbox rule) without preserving them first.
- Blaming the user for an approval-fatigue design weakness.
Each error was avoided in the night-time MFA case. The analyst revoked sessions and deleted the new authenticator before resetting the password, preserved the forwarding rule as evidence before removing it, and treated the clerk's approval as a design weakness; number-matching and security keys were the response, not discipline. Service principals and non-interactive sign-ins were included in the log export.
Exercises — chapter 7
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.
EX019 — Sequence. Steps: order these and justify: reset password; revoke sessions; export logs; remove new MFA method; check forwarding rules. Rubric: 3 = export, revoke, remove method, reset, check rules (or rules before reset with reason) with justification; 2 = one misplacement; 1 = reset first; 0 = none.
EX020 — Service account review. Steps: list four questions to ask about svc-patch after a compromise. Rubric: 3 = where used, privileges vs need, last rotation and credential storage, sign-in sources and anomalies; 2 = three; 1 = one; 0 = none.
EX021 — User communication. Steps: write a 60-word message to the clerk explaining what happened and what to do next without blame. Rubric: 3 = factual, no blame, clear next steps (report unexpected prompts, new sign-in method), contact; 2 = slightly blaming or vague; 1 = technical jargon; 0 = none.
Chapter synthesis
Identity is the commonest incident surface. Understand sessions and tokens, contain compromises in an order that removes all access paths, preserve before you change, retain identity logs long enough, and fix design weaknesses rather than blaming users.
Continue studying — chapter 07 of 30
← Chapter 06 · Course chapter index · Chapter 08 →
Continue to the next authored lesson.