8.2 Least Privilege and Separation of Duties

Key Concepts

Least privilege is among the most testable CC principles: a subject receives only the permissions required to perform assigned work, no broader and no longer than necessary. It is easy to state and hard to operate because access accumulates. People change teams, projects close, contractors extend, emergency access is granted, and "temporary" exceptions become permanent unless someone deliberately revokes them. The drift this creates is called privilege creep, and the standard countermeasures are periodic access reviews (recertification) and time-bounding grants with expiration dates.

Apply least privilege with four questions: What task must the subject perform? What object does that task require? What exact action on that object is needed? How long is the access needed? A marketing intern who builds campaign reports may need read access to selected analytics dashboards for the summer. The intern does not need platform administrator rights, export rights for all customer records, or any access after the internship ends.

Need-to-know is related but narrower: it asks whether a subject needs specific information to do the job. A nurse needs a patient's medication list to treat them; a billing clerk needs insurance and invoice fields but not full clinical notes. Least privilege includes need-to-know but also governs system actions like restart, approve, delete, configure, deploy, or create users. The exam often pairs them: information access leans on need-to-know, action/system access leans on least privilege.

Separation of duties (SoD), also called segregation of duties, divides sensitive tasks across multiple people or roles so no one person can both perform and hide an error or fraud. In finance, one person creates a vendor, a second approves it, and a third releases payment. In software delivery, a developer writes code, a separate reviewer approves the change, and an automated pipeline deploys it. In identity administration, a manager requests access, an application owner approves, and an identity team provisions.

SoD only works when the steps are meaningful and independent. A weak control demands two approvals but both come from the same person using two accounts. A strong control separates request, approval, implementation, and review, and logs each step so the organization can prove who did what.

Exam Application

Dual control and split knowledge are the heavier-duty cousins of SoD. Dual control requires two authorized people to act together on one sensitive operation (opening a vault, releasing a large wire). Split knowledge means no single person holds the complete secret, such as dividing a cryptographic recovery key into two halves held by different custodians. Reach for these when the risk is high enough that ordinary role separation is insufficient.

The table below shows how the same principle is named differently depending on what is split:

Work a fraud scenario. In a small company the office manager can create vendors, change bank-account details, approve invoices, and issue payments. That is efficient but is a textbook SoD failure: one person can invent a fake vendor and pay it. A better design lets the office manager enter invoices, requires a department manager to approve the purchase, and requires finance to approve before payment, with system-enforced amount limits and logged approvals.

Know the exam tell. When a scenario says a user has more access than the task needs, the answer is usually least privilege. When one person controls an entire high-risk process, the answer is usually separation of duties. Both are preventive controls (they stop harm before it happens), not detective controls.

The enduring challenge is balance. Too little access slows work and breeds risky workarounds (shadow IT, password sharing); too much access widens the blast radius of any compromise or mistake. Good access design is specific, reviewed on a schedule, time-bounded when appropriate, and tied to real job duties rather than convenience or title.

Where These Controls Fail in Practice

The exam frequently describes a broken control and asks what went wrong. Recognizing the failure modes is as valuable as defining the principle:

• Privilege accumulation through transfers. An employee moves from finance to marketing but keeps the old finance permissions. Each move adds rights, none removes them, until the account can touch far more than the current job requires. The fix is review at the moment of transfer, not only at annual recertification.
• Emergency access that never expires. "Break-glass" accounts granted during an outage are powerful by design. If they are not revoked and logged afterward, they become standing backdoors. The control is time-bounding plus mandatory post-use review.
• Cosmetic separation of duties. A process demands two approvals, but one person controls both approving accounts, or the same manager requests and approves. The steps look separate yet collapse into one actor. Genuine SoD requires different people and independent logging.
• Service accounts with human-grade rights. Automation accounts often accumulate broad permissions "to be safe." They rarely rotate credentials and are seldom reviewed, making them high-value targets. Least privilege applies to non-human subjects just as strictly as to people.

A final exam nuance: least privilege and separation of duties are both preventive administrative controls, and they reinforce each other. Least privilege shrinks what any one account can do; separation of duties ensures that even a maximally privileged single account cannot complete a sensitive process alone. Defense in depth means layering both rather than relying on either by itself, because a determined insider or a fully compromised credential can defeat any one control acting in isolation.