Case Study 2: The Trusted Insider — Least Privilege and Separation of Duties at a Regional Hospital

"Nobody we hired was a thief. The system simply let one person do, alone, what should have taken two — and so, eventually, one person did." — Director of Revenue Integrity, Lakeside Regional Health (constructed)

Executive Summary

To see why least privilege and separation of duties matter, it helps to leave the bank and study an organization where the threat is not an external attacker breaching a perimeter but a trusted insider quietly abusing access they were legitimately given. Lakeside Regional Health is a 400-bed hospital system where a billing specialist diverted roughly $180,000 over fourteen months — not by hacking anything, but by exploiting a workflow that let a single person create a vendor, approve a payment to it, and reconcile the books afterward. No firewall, no malware, no stolen credential was involved. The controls that failed were not technical at all; they were the principle controls of §3.4.

This is a design and governance exercise — the deliberate opposite of Case Study 1's detection-heavy analysis. Rather than classifying controls and hunting gaps in telemetry, you will redesign a broken business process using least privilege, separation of duties, and fail-safe defaults, and you will see that some of the most important security controls are administrative — policy and process — not technical. The scenario, the organization, and all figures are constructed for teaching (Tier 3), informed by the well-documented general pattern of insider financial fraud.

Skills applied: applying least privilege to human and system access; designing separation of duties into a real workflow; recognizing administrative controls as security controls; reasoning about the insider threat; using fail-safe defaults and dual control; distinguishing "trust the person" from "design the system."

Background

Lakeside Regional Health runs the way many mid-size healthcare systems do: lean back-office staff, software accumulated over two decades, and a culture that — admirably in most respects, dangerously in this one — runs on interpersonal trust. The accounts-payable function, where money leaves the organization to pay vendors, had been gradually consolidated. Years earlier, three people handled the steps; staff turnover and a "do more with less" mandate left much of it concentrated in one experienced, well-liked specialist named in this study only as the AP specialist. Everyone trusted them. That was precisely the problem, because trust is not a control.

Over fourteen months, the AP specialist set up a fictitious medical-supply vendor (using a real-looking name and a bank account they controlled), submitted modest invoices for plausible-sounding supplies, approved those invoices for payment, and then reconciled the accounts so the payments blended into normal expense patterns. Each individual payment was small enough to avoid scrutiny; the total reached roughly $180,000 before a new controller, reviewing vendor records during an unrelated audit, noticed a vendor with no contract, no delivery records, and a payment address that matched no known supplier.

When the security and audit teams reconstructed how it happened, they found something that surprised the hospital's leadership: every action the specialist took was within the access they had been granted. There was no break-in. The specialist's account legitimately allowed all of it. The failure was not that someone did something they were not permitted to do; the failure was that one person was permitted to do all of it. That distinction — between an access-control failure and a principle failure — is the lesson of this case.

🔗 Connection: This is the insider threat in its purest financial form, and it is exactly the threat that least privilege limits the reach of and separation of duties makes structurally difficult. Chapter 2's threat taxonomy lists "insider" as a category for a reason: a trusted insider already has authenticated access, already knows the systems, and is invisible to defenses pointed outward. You cannot firewall this away. The defenses are the principles in this chapter — and they are mostly administrative controls (policy and process), which is the second surprise for teams who think of security as technology.

The Analysis

Phase 1 — The broken workflow: one person, every step

The audit team's first artifact was a map of the payment workflow as it actually operated — not as any policy document described it. Drawing the steps and the actor for each made the flaw self-evident:

The accounts-payable workflow AS OPERATED (one actor throughout):

  [AP specialist] ──> 1. CREATE / onboard a new vendor  (add name + bank details)
        │
        ├──────────> 2. SUBMIT an invoice from that vendor
        │
        ├──────────> 3. APPROVE the invoice for payment
        │
        ├──────────> 4. RELEASE the payment (or queue it for the bank run)
        │
        └──────────> 5. RECONCILE the books afterward (mark it as matched/normal)

  Every step performed by the SAME person, with NO independent check at any point.
  Result: that person can invent a payee, pay it, and hide it -- alone.

Figure CS2.1 — The accounts-payable workflow as operated. A single actor controls vendor creation, invoice approval, payment release, and reconciliation. This is a complete violation of separation of duties: one person can perform every step of a high-risk financial process with no independent check.

The two principle failures are distinct, and naming both precisely is the point of the exercise:

• Separation of duties (the primary failure). The five steps form a high-risk process — money leaving the organization — and a single individual controlled all of them. There was no point at which a different person had to act. Separation of duties (§3.4) exists exactly to make this impossible: the person who creates a vendor must not be the person who approves payments to it, and neither should be the one who reconciles. With the steps split, the fraud would have required two or three people to collude — a dramatically higher bar that, in this case, would almost certainly have stopped it, because the specialist was acting alone.
• Least privilege (the enabling failure). Beyond the workflow, the specialist's account simply had too much. Over years of consolidation, it had accumulated the permissions for every step — vendor master-data edit rights, invoice approval authority, payment release, and reconciliation access — even though no single role legitimately needs all four. Least privilege (§3.4) would have scoped the account to one function. Privilege creep — the slow accumulation §3.4 warned about — had quietly assembled, on one human, the exact toolkit for fraud.

🛡️ Defender's Lens: Notice that neither failed control is technical. There is no firewall rule, no encryption setting, no SIEM alert that would have prevented this. The controls that should have been present are administrative (a separation-of-duties policy splitting the workflow) and a mix of administrative and technical (least-privilege role definitions, enforced in the AP software). New defenders reach instinctively for technical controls; this case is a reminder that for the insider threat, the most powerful controls are how you structure roles and processes. The §3.3 matrix had a whole administrative column for a reason.

Phase 2 — Redesigning with separation of duties

The fix is a redesign of the workflow so that no one person can complete it alone. The audit and security teams split the five steps across distinct roles, and — applying fail-safe defaults — made the system block a payment when the required independent steps have not occurred, rather than letting it proceed.

The accounts-payable workflow REDESIGNED (separation of duties enforced):

  ROLE A (Vendor Management)   ──> 1. CREATE / onboard a vendor  (with contract + verification)
                                        │  vendor enters a PENDING state; cannot be paid yet
                                        ▼
  ROLE B (AP Clerk)            ──> 2. SUBMIT an invoice against an APPROVED vendor only
                                        │
                                        ▼
  ROLE C (AP Approver)         ──> 3. APPROVE the invoice
                                        │   - MUST be a different person than the submitter
                                        │   - payments over $25k need a SECOND approver (dual control)
                                        ▼
  ROLE D (Treasury)            ──> 4. RELEASE the payment to the bank
                                        ▼
  ROLE E (Accounting, indep.)  ──> 5. RECONCILE -- a person in NONE of roles A-D

  Fail-safe default: a payment that has NOT passed each required, independently-actioned
  step is BLOCKED by default. The absence of an approval means "no", never "go ahead".

Figure CS2.2 — The redesigned workflow. The five steps are distributed across five role types, no one of which can perform another's step. High-value payments require dual control (a second approver). The system defaults to blocking a payment that has not cleared every independent gate — fail-safe by design. To defraud this process now requires collusion across multiple roles, not a single trusted insider.

Several principles are working together here, and seeing how they interlock is the heart of the case:

• Separation of duties distributes the five steps so that completing the process requires multiple distinct people. A lone insider — malicious, coerced, or simply error-prone — can no longer carry a payment from invented vendor to hidden reconciliation.
• Dual control on high-value payments adds a second independent approver above a threshold, so the largest, most damaging transactions require not just two roles but two approvers — raising the bar highest exactly where the stakes are highest.
• Least privilege is enforced by scoping each role to its single function: the vendor-management role cannot approve invoices; the approver cannot create vendors; the reconciler is deliberately barred from all of A–D. No account carries the full toolkit anymore.
• Fail-safe default governs the system's behavior when steps are incomplete: a payment that has not passed every required gate is blocked, not waved through. The absence of an approval defaults to no.

⚠️ Common Pitfall: Designing a beautiful separation of duties and then quietly defeating it with a "super-user" or an emergency override that one person controls. The audit team had to resist exactly this. A finance manager asked for an account that could "do everything in an emergency, so payroll never gets stuck." That account would have re-created the original single-point-of-fraud risk with a friendlier name. The team's answer was a tightly controlled break-glass procedure (Chapter 19): emergency override exists, but it requires two people to invoke, alerts the security team immediately, and is reviewed after every use. Separation of duties is only as strong as its weakest exception, and over-powerful administrative accounts are the most common exception that swallows it whole.

Phase 3 — Least privilege beyond the workflow: the access review

Redesigning one workflow fixes one process. But the root cause — privilege creep that had concentrated incompatible permissions on one account — could be lurking elsewhere across the hospital. So the security team paired the workflow redesign with a recurring access review: a periodic, mandatory check that each account holds only the access its current role requires.

The first review, run across the finance and clinical-billing systems, found the kinds of things every first access review finds:

First access review — representative findings (finance + billing systems):

  - 3 accounts with BOTH vendor-creation and payment-approval rights
        -> incompatible duties on one identity; REMOVE one from each
  - 1 former contractor account, still active 8 months after the contract ended
        -> orphaned account; DISABLE immediately
  - 11 staff in an "AP-PowerUsers" group that nobody could explain
        -> group grants broad rights; AUDIT membership, scope to need
  - 1 service account for the billing integration with interactive-login enabled
        -> a machine account that can be logged into by a human; HARDEN
  - 5 clinical staff with read access to the full vendor-payment ledger
        -> no business need; REVOKE (least privilege)

🔗 Connection: This is least privilege operationalized as a process, not a one-time setting — exactly the point §3.4 made about privilege creep. A single configuration cannot hold least privilege over time, because roles change, people cover for each other, and one-off grants are never revoked. Only a recurring access review (Chapter 18 builds the full identity-governance discipline around this) keeps the creep in check. Note also that the review is itself a detective administrative control — it does not prevent over-provisioning; it finds it after the fact. The redesigned workflow is the preventive control; the access review is the detective one that catches what slips through. Defense in depth (§3.5) applies to financial fraud just as it applies to network intrusion.

Phase 4 — Why this is a security problem, not just an accounting one

A reasonable skeptic — perhaps a hospital executive — might object: this is an internal-controls and audit issue, the finance department's problem, not cybersecurity's. The audit team's answer reframed the whole incident, and it is worth stating clearly because it generalizes far beyond Lakeside.

The principles that failed — least privilege, separation of duties, fail-safe defaults — are security principles, and they protect integrity, the second leg of the CIA triad (§3.1). The fraudulent payments were an attack on the integrity of the hospital's financial records: data (vendors, invoices, payments) created and approved by an unauthorized-in-spirit actor, blended into the books to appear legitimate. The fact that the "attacker" was an insider with valid credentials does not move it out of security's domain — it moves it to the center of it, because (Theme 3) the human is both the weakest link and the strongest asset, and (Chapter 2) the insider is a first-class threat actor. The same separation-of-duties principle that stops financial fraud also stops a compromised employee account from completing a sensitive action alone — which is why the very same control protects the bank's wire transfers in §3.2 against a phished credential. One principle, two threats (the malicious insider and the external attacker who has compromised one insider), one structural defense.

🚪 Threshold Concept: Security is not only the technology that keeps outsiders out; it is the structure that ensures no single actor — human or account, malicious or compromised — can cause outsized harm alone. The most elegant security controls are often not gadgets but the shape of a process: who must act, in what order, with what independent checks. Once you see that designing a workflow so two people are required for a dangerous action is the same idea as requiring two independent layers to stop an intrusion, the principles of this chapter stop being a list and become a single way of thinking — no single point of failure, whether it is a control or a person.

When Lakeside's leadership absorbed this, the workflow redesign and the access-review program were funded not as an "accounting fix" but as part of the security program, owned jointly by the security and internal-audit functions. The hospital had learned the expensive way what this chapter teaches up front: some of your most important security controls are administrative, the insider is a real adversary, and least privilege plus separation of duties are how you make sure that trusting your people does not require betting the organization on every one of them.

🔄 Check Your Understanding: The redesigned workflow requires a different person at several steps, and dual control (two approvers) above $25,000. A board member asks: "Doesn't this just slow everything down? Why not trust our well-vetted staff and skip the overhead?" Answer in two or three sentences, using the distinction between trusting a person and designing a system, and name what residual risk remains even after the redesign. (Hint: separation of duties defends against more than malice.)

Discussion Questions

1. Every control that should have prevented this fraud was administrative (policy and process), not technical. Why do organizations — and new security practitioners — so consistently underweight administrative controls? What does this case suggest about where a security program should look first for insider risk?
2. The finance manager wanted an emergency "super-user" account so payroll would never get stuck. Make the strongest case for that account, then explain how a break-glass procedure (Chapter 19) preserves the legitimate need while protecting separation of duties.
3. Separation of duties stops a lone bad actor but can be defeated by collusion between two people in different roles. Is separation of duties therefore pointless? Argue why raising the bar from "one person" to "two colluding people" is a major security win even though it is not absolute.
4. This case treats an insider with valid access as a threat actor. How does defending against a trusted insider differ from defending against an external attacker, and which principles in this chapter work against both?
5. Compare this case study with Case Study 1 (Meridian's control framework). One is about finding gaps in a defense through analysis; the other is about designing a process so no single actor can cause harm. What does using the same set of principles for two such different problems tell you about how general these principles are?

Your Turn

Choose a high-risk process in an organization you know — issuing refunds, granting system access, publishing to a live website, approving expenses, dispensing controlled medication, changing grades — and redesign it for security using this chapter's principles:

1. Map it as operated. Draw the steps and the actor for each, the way Figure CS2.1 does. Be honest about where one person currently controls multiple steps.
2. Find the principle failures. Identify every place that violates separation of duties (one person completing a high-risk process) and least privilege (an account or role with more access than its function needs).
3. Redesign it. Split the steps across roles so no one person can complete it alone; add dual control for the highest-stakes cases; scope each role to least privilege; and choose a fail-safe default for what happens when a required step is missing (it should block, not proceed).
4. Name the residual risk. State what could still go wrong after your redesign (collusion? an over-powerful admin? an emergency override?) and one control that would address it.

Keep it to one page. The test of a good answer is simple: after your redesign, can any single person — acting alone, whether malicious or merely mistaken — still cause the harm you were worried about? If yes, the separation is not yet real.

Key Takeaways

• The most damaging insider abuses often involve no break-in at all: every action is within the access the person was granted. The failure is not unauthorized access but one person being permitted to do everything.
• Separation of duties is the structural defense: split a high-risk process across distinct roles so completing it requires multiple people, turning solo fraud into a collusion problem.
• Least privilege is the enabling defense: scope every account and role to its single function so no identity accumulates the full toolkit for harm. Its enemy, privilege creep, is fought with recurring access reviews — a detective control behind the preventive workflow design.
• Some of the most important security controls are administrative (policy and process), not technical. For the insider threat, how you structure roles and workflows matters more than any gadget.
• Fail-safe defaults and dual control complete the design: incomplete processes block by default, and the highest-value actions require a second independent approver — raising the bar highest where the stakes are highest.
• These are integrity controls (CIA triad) and they defend against both the malicious insider and the external attacker who has compromised one insider — one structural idea, two threats.
• Watch for the exception that swallows the rule: an over-powerful admin or emergency override can silently defeat separation of duties. Manage it with a tightly controlled, alerted, reviewed break-glass procedure, never an ungoverned super-user.
• The deep principle behind the whole chapter: no single point of failure — whether that point is a control or a person.