Two Admin Accounts, Six Engineers, One Departed
A hospital's EHR is administered by six engineers who share two domain administrator accounts because 'individual accounts break the ETL jobs.' The passwords sit in a shared vault the whole team can open. Logs show the two accounts performed 340 privileged actions last month, 60 of them between 01:00 and 04:00. One engineer left the hospital 11 days ago; the shared password has not been changed, and the accounts have been used twice since. A SIEM rule alerts on failed logins but not on privileged activity. The CISO's position is that shared accounts are acceptable because the team is small and 'everyone knows everyone.' The hospital must meet a regulatory requirement for unique user identification and audit-trail attribution.
1. How should you assess the CISO's rationale, and what turns this from a theoretical risk into an incident?
Read the worked answer
The 'small trusted team' argument fails on three separate grounds, and one of them is no longer hypothetical.
Failure 1 - it contradicts a stated obligation. The regulatory requirement is unique user identification and attributable audit trails. Whether the team is two people or two hundred, shared credentials cannot produce attribution. A rationale that argues the control is unnecessary does not satisfy a requirement to have it.
Failure 2 - trust is not a control. 'Everyone knows everyone' is a statement about intent; controls address mistakes, coercion, and departure. Six people sharing one identity means no one is accountable for any specific action, and no one can be exonerated either. Shared accounts protect the guilty and fail the innocent equally.
Failure 3 - the departed engineer. This is the decisive point. The password was not rotated 11 days after an engineer with knowledge of it left, and the accounts were used twice since. Two possibilities: a current employee used them (non-attributable, a control failure) or someone unauthorised used them (a security incident). You cannot currently tell which, and that inability is the finding.
The auditor's response should stop treating this as a policy debate and open it as a potential unauthorised access investigation: preserve the logs, identify the source workstations and session details for the two post-departure uses, and escalate immediately rather than at report stage.
2. What is the priority remediation, and which interim compensating controls are genuinely valid?
Read the worked answer
Priority one is immediate containment, ahead of any architectural fix.
- Rotate both shared credentials now and obtain confirmation of the two post-departure sessions. This is hours, not weeks, and does not require a project.
- Formally remove the departed engineer from every access path - vault membership, VPN, badge, password-reset questions. Verify rather than assume; the fact that the password was not rotated suggests offboarding was not systematic.
Then the structural fix, driven by the actual root cause:
- The ETL jobs should never have been running under a human administrator identity. Separate machine identity from human identity. The jobs get service accounts with tightly scoped permissions and no interactive logon; humans get individual named accounts with just-in-time elevation. Naming this distinction is what dissolves the engineers' objection - the ETL breakage they fear is caused by human credentials in automation, not solved by it.
Valid interim compensating controls:
- Vault checkout with individual credentials, so each retrieval is logged to a person, with approval and time-boxed release.
- Full session recording for privileged sessions, reviewed on a sample basis.
- Alerting on privileged activity - including out-of-hours use, which is already visible in the data (60 actions between 01:00 and 04:00 warrant an explanation, not just a rule).
Not valid as compensation: 'we review the logs' when the logs cannot attribute actions to a person. Log review on a shared account reviews nothing.
3. What evidence would actually demonstrate that privileged activity is attributable, and how does the SIEM gap fit in?
Read the worked answer
Test attribution end to end on a sample of real actions; the existence of logs is not the assertion.
Take a sample of the 340 privileged actions and attempt to trace each to a named individual, a business justification, and an approval. The evidence is the trace, not the log file. Specifically:
- Selection of actions from the privileged-account logs, deliberately including several of the 01:00–04:00 events.
- Reconciliation to a person via vault checkout records, session recordings, ticketing, or change records. Any action that cannot be traced is a failed test item - and the failure rate on the sample is your finding, stated numerically.
- A walk-through of one action with the engineer who performed it, confirming they can identify their own activity. If two engineers cannot tell you who did a given change, attribution does not exist regardless of what the logs retain.
- Evidence of review, not just retention: minutes or tickets showing a supervisor examined privileged activity and acted on exceptions.
On the SIEM gap: the rule alerts on failed logins but not privileged activity. That means the detective control watches the perimeter and ignores the position of maximum damage - a successful compromise of a domain admin produces no alert at all. The 60 out-of-hours actions are exactly the pattern such a rule would catch. Fix the alerting, but do not let it substitute for individual accounts: alerting on a shared account tells you that someone did something unusual, which is a weaker statement than knowing which engineer to ask.