Approval Workflow Bypassed by an Emergency Access Path
A hospital's Password Safe deployment requires dual approval for any checkout of domain administrator credentials during business hours. A separate 'break-glass' policy exists for after-hours emergencies: it allows a single approver and auto-approves if no approver responds within 10 minutes. Over one quarter, 38 break-glass checkouts occurred. Audit review finds that 31 happened during business hours, all by the same three engineers, and that in 22 cases the auto-approve timer fired. The engineers say the standard dual-approval queue was 'too slow' for incident response. The CISO wants to tighten the break-glass policy but is worried about delaying genuine emergencies.
1. Assess the control design. What specifically made this bypass possible, and which signals indicate abuse versus legitimate use?
Read the worked answer
The break-glass path was designed as an exception but implemented as a parallel, always-available route with weaker controls. Three design flaws combined:
- No scoping to the exception condition. The policy is described as 'after-hours' but evidently does not enforce a time window or incident reference, so it is usable at 2 p.m. on a Tuesday.
- Auto-approve on timeout. A 10-minute timer that grants access by default inverts the control: silence becomes consent. This is the single most dangerous element - 22 of 38 checkouts were never actually approved by a human.
- No post-hoc review gate. Nothing forces a break-glass checkout to be justified after the fact, so the path carries no accountability cost.
Signals pointing to routine use rather than emergency:
- 31 of 38 during business hours contradicts the 'after-hours emergency' premise.
- Concentration in three engineers suggests habit, not distributed emergency need.
- The stated reason ('too slow') is a process complaint, not an incident.
Legitimate break-glass use should be rare, time-boxed, tied to a ticket or incident ID, and reviewed afterward. A pattern this dense and this concentrated is a workflow problem masquerading as an emergency.
2. Propose a tightened design that preserves genuine emergency access without the auto-approve hole.
Read the worked answer
Keep the emergency path but make it narrow, attributable, and reviewed:
- Remove auto-approve-on-timeout. If no approver responds, the request should escalate to a secondary approver list (e.g., on-call security lead) or fail closed. Default-deny is the correct posture for privileged access.
- Require an incident reference at request time. The engineer must enter a ticket/incident ID; the request is blocked without one. This alone filters casual use.
- Bind the exception to conditions. Enforce the after-hours window, or require an explicit 'declare emergency' action that is itself logged and triggers immediate notification to the CISO and the engineer's manager.
- Time-box and auto-revoke. Grant access for a fixed duration (e.g., 60 minutes) with automatic credential rotation or checkout revocation at expiry.
- Mandatory post-hoc review. Every break-glass event generates a review task within 24 hours; unreviewed events escalate. Report on frequency and concentration monthly.
- Fix the root complaint. If dual approval is 'too slow,' measure the actual queue latency. If it is genuinely slow, add approvers, enable mobile approval, or pre-approve specific low-risk credential sets - do not weaken the high-risk path.
This preserves emergency access while making each use visible, justified, and bounded.