Case Study: The Unrevoked Contractor & Apple v. OpenAI

Reasonable designs differ in details; what earns marks is that every Read or Write is backed by a real task, and everything else is None. A strong model answer:

Notes on the reasoning:

• Doctor vs. Pharmacist on Pharmacy: both have Write, but to different functions: doctors create prescriptions, pharmacists verify and dispense. Neither can complete the whole drug chain alone, which is also Separation of Duties.
• Nurse on Pharmacy is Read, not Write: nurses administer what is ordered; they do not change orders.
• Billing Staff is a classic least-privilege case: the role “can view invoices only.”
• IT Admin: administrators maintain the systems (configuration, accounts, backups) but are not clinicians, so they should never have Write access to clinical content. Read access to records should be limited to troubleshooting, ideally granted temporarily per support ticket, and always logged. This is exactly the access the Part 2 scenario says the IT Support role should have had.

Best fit: RBAC, refined with ABAC rules where context matters.

Why RBAC as the base:

• The table itself is a role-to-permission mapping: five roles, each with a fixed set of permissions. That is exactly how RBAC works.
• With about 800 staff, RBAC is easy to manage: a new nurse is assigned the Nurse role and receives exactly the right access on day one (clean provisioning), and moving or leaving staff are handled by changing or removing role assignments (change and deprovisioning).
• It is the most widely used model and easy for non-technical managers to review.

Why add ABAC refinements: RBAC alone gives a nurse access to every patient’s chart. Least privilege is better served by attribute rules such as “only patients under her care, only during her shift, only from a hospital device,” and for IT Admin, “Read only with an open support ticket.” Writing these as ABAC rules avoids role explosion (creating hundreds of ward/shift roles).

Why not the others as the main model:

• DAC: letting each record “owner” share at will gives the hospital no central control over sensitive health data.
• MAC: too rigid for everyday hospital work, although MAC-style labels can still protect a small set of extremely sensitive records (e.g. psychiatric records labelled Restricted).

Deprovisioning failed. Somchai left two weeks ago, but his account was never disabled, so it remained a working identity with no legitimate owner.

What should have happened: his account should have been disabled on his last day (MediCare Plus’s Access Control Policy requires revocation within 24 hours of any role or employment change), triggered automatically by the end date of his contract, with the quarterly access recertification as a safety net to catch any account that slipped through.

Weakness: single-factor authentication: only a password (something you know) was required, even for a login from outside the hospital network. Anyone who knew, guessed or stole Somchai’s password could log in as him.

With MFA: the login would also need a factor from a different category, such as a code from Somchai’s registered phone or a hospital badge (something you have). An attacker with only the password would have been blocked. Even if Somchai himself was the one logging in, MFA would not fix the real root cause (the account should not have existed), but combined with deprovisioning it would remove the easiest path in.

No. Least privilege means only the access a role strictly needs. Contractors in IT Support only ever needed Read access, to troubleshoot the system when it broke down. Instead, the role had Write access to all medication records for every patient: far more than the job required. That excess is exactly what turned an unrevoked account into a patient-safety incident (a changed medication order) rather than just a privacy problem.

What it should have had: Read-only access, ideally limited in scope and time (for example, only while a support ticket is open), and never Write access to clinical medication orders, which belong to doctors and pharmacists.

How it was found: not by any security system. A pharmacist noticed the order looked wrong and then checked the access log for that patient’s record, which showed Somchai’s account, the 11:40 PM time, the outside-network origin and the password-only login.

What it tells us:

• Even though the logs did not prevent or immediately detect the change, they made it possible to reconstruct what happened (forensics), identify which account was used (accountability) and show what was changed so it can be corrected.
• Without the log, the hospital could not even prove the order had been tampered with.
• But it also shows a gap: nobody was monitoring the logs. An alert on “login from outside the network, by a contractor account, at night, editing medication records” could have caught it immediately.

Accounting matters after the fact because it is the evidence; it matters before the fact only if someone actually reviews it.

Yes, very likely. ABAC decides each request from user, resource and environment attributes in real time, so even with the account still active, the context of this request would have failed the checks.

Example rules (any one is enough):

• Employment-status attribute: “Allow access only if user.employment_status = Active and today’s date is on or before user.contract_end_date.” Somchai’s contract had ended → denied.
• Location / device attribute: “Allow Write to medication orders only from hospital-network devices.” The login came from outside → denied.
• Role + action attribute: “Allow Write to medication orders only if user.role is Doctor or Pharmacist.” IT Support → denied.

ABAC does not replace deprovisioning, but it adds a second, independent layer (Defense in Depth).

Any two concrete, checkable recommendations; strong examples:

1. Automatic deprovisioning (Identity): “All contractor accounts must be created with an expiry date equal to the contract end date and are disabled automatically on that date. HR must notify IT of any early departure, and IT must disable the account within 24 hours. A quarterly access review checks for any active account without a current contract.”
2. Least privilege + MFA (Authorization, Authentication): “The IT Support role is reduced to Read-only access to the Pharmacy System, granted only while a support ticket is open. MFA is required for all remote logins and for any change to medication orders.”

Other good answers: an alert to the security team for any medication-order change made by a non-clinical role or from outside the network (detective, Accounting); ABAC rules as in P2-Q5.

Stage: if the allegation is true, it points to a failure of deprovisioning: access should have been removed when he left, but (according to Apple’s complaint) it still worked afterwards.

Shared responsibility:

• The organization (Apple, in this hypothetical) remains primarily responsible: it decides who should have access and must make sure leaving staff are removed from every system, including third-party services, not just internal ones.
• A third-party cloud vendor could share some responsibility depending on the contract: for example, whether its platform made it easy to revoke access centrally, whether access was tied to the company’s central identity system, or whether separate vendor accounts existed that the company’s offboarding process did not cover.

Lesson for security managers: offboarding checklists must cover all accounts, including cloud and vendor-hosted ones, ideally by connecting them to a single central identity so that disabling one identity cuts off everything.

Least privilege question: an engineer should have access only to the files his current work requires. If, as alleged, a single engineer could reach and download dozens of confidential files (including material such as a circuit schematic), it is worth asking whether all of that was needed for his role, or whether access had built up over time. We cannot know from the complaint what his job actually required; the point is that the organization should be able to answer that question.

Lesson for current employees: access reviews should not happen only at the exit door. Periodic access recertification (e.g. quarterly) for current staff, plus removing old access at every role change, keeps access matched to the job. Then, even if deprovisioning fails, the leftover access is small, which limits the damage.

According to the reports, the evidence Apple relies on came from a forensic review after the fact, not from a real-time alert. This shows that accounting must support investigation and legal proof, not only detection:

• Forensics: logs must capture enough detail (which account, which file, when, from where) to reconstruct events weeks or months later.
• Integrity: records must be tamper-resistant and not editable by the people they watch, or they will not stand up as evidence in a dispute or court.
• Retention: logs must be kept long enough to still exist when a problem surfaces long after it happened.
• Coverage: logging must include third-party/cloud services, not only internal systems.

And the reverse lesson: real-time monitoring (e.g. alerting on a departed employee’s account being used, or on bulk downloads) could have flagged the alleged activity much earlier, if such controls had been in place.

The key idea: don’t let security depend on the departing person’s cooperation. If offboarding relies on the employee attending an interview and signing documents, anyone who persuades them not to cooperate defeats it. Controls should take effect automatically:

1. Automatic, cooperation-free revocation (Fail-Safe Defaults): all accounts, including cloud and vendor accounts, are disabled on the last working day, triggered by HR’s record, whether or not the exit interview happens.
2. Obligations signed at the start, not the end: confidentiality and return-of-property obligations are signed at onboarding and in the employment contract, so refusing to sign at exit changes nothing.
3. Separation of Duties: offboarding is completed by HR + IT + the department head, each signing off their part, so no single person (or a skipped meeting) can leave access open.
4. Monitoring around departures (Detective): extra review of downloads and access in the notice period, and alerts if a departed person’s account is used.
5. Device and data return verified against an inventory, with remote wipe for hospital devices that are not returned.

Final answer: make offboarding automatic and multi-layered, so bypassing the exit interview does not leave any access or data in the departing employee’s hands.

There is no single “correct” verdict here (and no court has ruled on these allegations), but a strong answer reasons about both:

• Individuals remain responsible for their own actions: an employee who knowingly takes confidential data breaks their obligations regardless of who encouraged them.
• If a failure is systemic, as Apple alleges (many people, a repeated method, guidance coming from the hiring organization), then responsibility also extends to the organization that created or encouraged the pattern. Systemic problems come from incentives, culture and instructions, and blaming individuals alone would not stop them repeating.
• From a security-management view, a systemic pattern also asks questions of the organization that lost the data: if many departures could, as alleged, sidestep its process, its offboarding controls depended too much on individual cooperation (see Apple Q4).

Final answer: systemic failures point to shared responsibility. Individuals stay accountable for what they do, but an organization that shapes the behaviour (and an organization whose controls allow it repeatedly) also bears responsibility. Always remember: in this case these remain allegations.