IAM Chapter 8, Part 1: What Nobody Removes

Part of the IAM study series.

Chapter 7 gave every change an event: joiner, mover, leaver. But provisioning has an event for everything except this is no longer needed. Between those events nothing fires, for six years, and access only ever goes up. Governance is everything that works in that gap.

1. Recertification, and Why Campaigns Mostly Do Nothing

An event fires and the system reacts. Recertification is the periodic sweep for the gap between events.

What Winston is sent: 12 reports × 40 entitlements = 480 decisions, 20 minutes before his next meeting. That's 2.5 seconds each. "Select all → approve" isn't laziness; it's the only behaviour the design permits.

He can't evaluate the item. SAP_FI_GL_POST_03 tells him nothing: not what it grants, not whether it's used, not what breaks on Monday if he removes it. Approving is the rational choice, and it stays rational however many reminders you send.

What he should be sent:

• Review the role, not the 40 things it grants. "Is John still a design engineer?" is one question he can actually answer.
• Show only the exceptions: direct grants outside any role, anything unused for 90+ days, privileged access, SoD conflicts. Everything else auto-renews.
• Give him enough to decide: a plain-language description, the last-used date, who else holds it, and the original justification. Last-used does more work than all the others, and most organisations don't have it, which makes usage telemetry a prerequisite project.
• Micro-certification. One review fired by a change (a mover, a direct grant, an escalation): one decision, in context, at the moment it means something, instead of 480 in a batch.

The number that says whether it's real is the revocation rate. A campaign returning 99% approved did nothing; you bought an audit artifact, not a control. But 97% can be healthy if the scope was pre-filtered to exceptions, so the rate is meaningless until you know what was in scope. Then check time per decision (2 seconds means nobody reviewed) and variance between reviewers (perfect uniformity is the tell). Or just sample 50 approvals against last-used.

2. Separation of Duties: The Combination, Not the Entitlement

Create a supplier is part of her job. Approve a payment is part of her job. Together they are pay a supplier that does not exist. Neither half is wrong; the combination is, and recertification reviews each line separately and nods at both.

A toxic combination is a pair (or set) of entitlements that must not coexist on one identity. The threat model is an insider who is exactly who they claim to be, using access they legitimately hold, in a sequence that defrauds the company.

The part that's actually hard: rules are written in business language (create vendor vs approve payment), but enforcement happens against SAP_FI_VEND_CREATE. Someone must map every business function to real entitlements in every system. That mapping is the project, and it rots whenever an app changes its permission model. It's where stalled SoD programmes nearly always stalled.

Preventive vs detective:

• Preventive, the gate: request → SoD check → granted. Clean and cheap. But role membership, app-admin changes, emergency access, migrations and acquisitions all bypass the gate.
• Detective, the sweep: scan the whole estate and report violations. It's the only thing that sees the side doors.

Check SoD at role-definition time, not just request time. A business role bundling both halves gives the violation to everyone who holds it, silently, and your request-time check never fires, because nobody requested two entitlements. They requested a job.

When you can't separate (one finance officer at a small site, no second person) you use a mitigating control: documented, owned, evidenced, usually a second-party review after the fact. Auditors accept this. What they don't accept is an undeclared violation. Model the two roles separately anyway; that turns an invisible risk into a detectable one.

But after-the-fact review fails for export control. A payment can be clawed back. An unlicensed export can't be un-exported; the violation completed at release. So choose preventive or detective by whether the harm is reversible. Irreversible means preventive only, and you pay the latency. Best of all, make it a system rule: refuse to record a release unless a valid licence reference exists. That's Chapter 6's ABAC, and it doesn't go on leave or do favours on a Friday.

3. Least Privilege, Made Measurable

"Users shall have the minimum access necessary." Minimum over what period? Necessary according to whom? As written it binds nothing, which is why it's in every policy and changes no decisions.

Two computable definitions make it real:

• Unused: granted, but not exercised in N days.
• Over-scoped: write where only reads happen; all 11 plants where only one is ever touched.

That percentage is your least-privilege number, and unlike the policy sentence, it moves. The first measurement usually lands at 40–60% unused, worse than anyone expected, and better than any argument at convincing a steering committee.

Two constraints, and the second is worse.

• Telemetry. Most enterprise apps log logins, not which entitlement was exercised. Cloud does this well (Access Analyzer, Entra PIM, GCP's recommender); on-prem often can't. "Unused" may mean "invisible", and a 90-day window against 60 days of logging is partly blind, which nothing will flag.
• Organisational. Removing unused access raises a ticket when you're wrong and nothing when you're right. It needs executive cover and Chapter 7's rollback window.

90 days is the wrong threshold on its own. Quarterly close, a certification milestone, an annual submission: the longest-cycle entitlements are often the highest-impact ones, and at 90 days "used once a year" looks identical to "never used". Exceed the longest legitimate business cycle, vary it by type, and never auto-revoke: notify the owner, then revoke with rollback.

Exposure = scope × time held. A narrow grant held for six years can be worse than a wide one held for four hours. Shortening duration beats trimming scope. Chapter 7's time-bound grants and Chapter 6's standing-vs-JIT do more for least privilege than any role redesign will.

Least privilege isn't need-to-know. John and Sofia are both design engineers with PLM read: identical role, identical permissions. John's licence covers him and he's assigned to Engine X. Sofia is on a different programme. The drawing (programme Engine X, export class controlled) is fine for one and not the other.

• Least privilege = capability: what you can do, a property of your permissions.
• Need-to-know = information: which items you may see, a property of you and that item.

You can be perfectly least-privileged and still be shown data you have no right to. This is what broke RBAC for export control. The role is identical; the answer differs per person and per document: nationality, licence coverage and programme assignment against classification, programme and export category, at the moment of access. That's ABAC, and export control is why most aerospace companies had to build it (Part 3).

What Breaks in Practice

🔴 CHECKPOINT: Study Notes

← Previous: Nobody to Ask · Back to the series start · Next: Blast Radius →