Chapter 7 — Identity and access foundations
Lesson map
Lesson 07 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Three decisions"]
N2["7.2 Shared and leftover accounts"]
N3["7.3 Multi-factor and recovery paths"]
N4["7.4 Least privilege as a checklist"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Three decisions"]
N2["7.2 Shared and leftover accounts"]
N3["7.3 Multi-factor and recovery paths"]
N4["7.4 Least privilege as a checklist"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX019"]
[Learning outcomes]
|
v
[7.1 Three decisions]
|
v
[7.2 Shared and leftover accounts]
|
v
[7.3 Multi-factor and recovery paths]
|
v
[7.4 Least privilege as a checklist]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes
You will (1) describe authentication, authorization and accounting as separate decisions; (2) explain why shared and leftover accounts appear so often in assessments; (3) map common identity weaknesses to ATT&CK technique IDs; (4) design a least-privilege checklist for a staff portal.
7.1 Three decisions
Authentication answers "who is this?" Authorization answers "what may they do?" Accounting answers "what did they do?" A system that authenticates strongly but authorizes everyone as administrator has only solved the first question. Findings should say which decision failed.
On TRT's portal the three can fail independently: a correct password used with a leftover contractor role is still a finding. F-07's leftover VPN roles show authorization drift while authentication still works, and the missing accounting trail belongs to the same family of findings. Priya scores each decision separately in the write-up, so owners know which control to fix.
7.2 Shared and leftover accounts
Shared passwords for "the ops account" destroy accountability: nobody knows who used it. Leftover accounts of contractors and former staff are a classic source of unexpected access. ATT&CK catalogues the adversary use of legitimate credentials as T1078 Valid Accounts, and the creation of new accounts as T1136 Create Account. Mapping a finding to these IDs lets defenders search the same patterns in their own logs.
Shared ops passwords destroy the accounting leg; F-07 tracks ex-contractor VPN accounts for the same reason. ENG-712 recommends named accounts and revocation dates, not another shared secret.
7.3 Multi-factor and recovery paths
A second factor raises the cost of stolen passwords. Recovery paths — SMS reset, help-desk override, backup codes — must be protected at the same level, or they become the weak door. MFA request generation (ATT&CK T1621) is an adversary technique against push-based factors; that is a design concern for purple-team exercises, not a cue to disable MFA.
When the ROE allows it, Priya's method statement includes a review of the staff portal's recovery paths, including SMS reset and help-desk override. A strong MFA design with a weak reset process is filed as a finding rather than ignored. The review stays at configuration and process level and does not involve triggering push requests at real staff.
7.4 Least privilege as a checklist
For each role on the staff portal: list the actions it needs, remove the rest, and record who can grant exceptions. The checklist is evidence that authorization was designed rather than inherited.
Least privilege for portal roles is a written checklist signed by the app owner. Exceptions list who granted them and when they expire. The checklist is attached as evidence beside F-01; an unsigned checklist does not count as least-privilege evidence. At each retest Priya re-reads the exceptions list, because an expired exception that still grants rights is itself a finding.
Worked example
Priya reviews TRT's VPN account list. Three accounts belong to contractors whose contracts ended months ago. She records a finding under T1078, evidence E-010 (the account export with last-login dates), and recommends disablement plus a quarterly review. She does not attempt to use the accounts.
Synthetic case. The leftover contractor accounts are fictional TRT examples.
Errors and limits
Listing accounts is not the same as proving they can be used; that step needs explicit authorization. Do not store recovered passwords in tickets.
Exercises
- EX019 — Which decision? A portal lets any authenticated staff member edit the public timetable. Which of AAA failed, and what is the fix direction? Rubric: 3 = authorization; restrict edit to a publisher role; 2 = authorization only; 1 = authentication; 0 = none.
- EX020 — ATT&CK mapping. Map "ex-contractor VPN accounts still enabled" to a technique ID and name. Rubric: 3 = T1078 Valid Accounts; 2 = T1078 or Valid Accounts alone; 1 = wrong ID; 0 = none.
- EX021 — Recovery path. Name one recovery-path weakness that can undo MFA and a mitigation. Rubric: 3 = e.g. weak help-desk reset / SMS interception / unprotected backup codes + matching mitigation; 2 = names weakness; 1 = disable MFA; 0 = none.
Synthesis
Separate who, what and what-was-done; retire leftover accounts; map identity findings to ATT&CK so defenders can hunt them.
Continue studying — chapter 07 of 30
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →