Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

When do we…

When do we use a break-glass account, and what must happen afterwards?

5 decision pointsThe pack behind this answer: Privileged Access Management

Add to board memo

The short answer

Recommendation
Use a break-glass account only when the normal administration route itself is unavailable, such as when every administrator is locked out. Afterwards, declare the use, confirm the alert, have every action reviewed, change and reseal the credential, and close the record only once the cause is fixed.
Reasoning
A break-glass account bypasses the normal route, so its safeguards are the seal, the two-person safe, the alert on every sign-in and the review afterwards. Urgency alone is not a reason: if the normal route works, even slowly, an ordinary or out-of-hours elevation does the job with an independent approver. The review compares every action with the declared reason, from a log the account cannot change, so anything outside that reason shows up.
Considerations
  • The 1-working-day review and reset, and the test every 3 months, are the CISO Times privileged access pack's defaults (PA-12). Your own standard may set others.
  • Name the reviewer of every use in advance. One use not reviewed on time puts the pack's on-time measure outside tolerance, and that goes to the next executive committee with its plan.
  • An action nobody can explain, a change to logging or a sign-in nobody declared is a sign of compromise. Report it as an incident at once, and change the credential at once.
  • Where a provider runs your IT, its on-call engineer may use the account. Your Head of IT still owns the accounts and the safe, and the review is never left to the provider.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
StartSomeone wants to use a break-glass accountDecisionIs the normal administration route itself unavailable?OutcomeUse normal elevation, or the on-call route out of hoursStepDeclare the use and its reason, before signing in if you canStepOpen the safe with two people and sign inDecisionDid the sign-in alert reach the named people?StepRaise the missing alert as a finding of its ownStepDo only what brings the normal route backStepHave the Head of Information Security review every actionDecisionDoes every action match the declared reason?StepRecord each unmatched action and ask for an explanationDecisionIs there any sign of misuse or compromise?OutcomeContain it and report a security incidentStepChange the password and key, and reseal themDecisionWere the review and the reset both done within 1 working day?StepFinish the late step and report the measure outside toleranceOutcomeFix the cause and close the record with the reviewer's name

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 17 steps.

  1. Start

    Someone wants to use a break-glass account

    A break-glass account exists for the day the normal administration route fails, and for nothing else. It is a cloud-only account not tied to any one person's device or phone, sealed in a two-person safe, alerting on every sign-in, and tested every 3 months. Any authorised administrator may use it, including a provider's on-call engineer, but only in that case.

    In the pack

  2. Decision

    Is the normal administration route itself unavailable?

    Valid: every administrator is locked out, as when a faulty sign-in policy shuts them all out of the cloud tenant. Not valid: the normal route is slow, or the usual approver cannot be reached; out of hours there is an on-call route for that. Using the break-glass account because the normal route is slow is one of the shortcuts the pack rules out.

    In the pack

  3. Outcome

    Use normal elevation, or the on-call route out of hours

    If the normal route works, the task goes through an ordinary elevation, however urgent. Out of hours, phone an approver on the on-call list, never yourself: the window is no longer than 4 hours, and the approval goes on the ticket within 1 working day. Urgency is never approval.

    In the pack

    See also

  4. Step

    Declare the use and its reason, before signing in if you can

    The user declares the use to the Head of IT, or to the Head of Information Security if the Head of IT is unavailable, with the reason, before signing in or at once after. In the pack's example, the provider's on-call engineer declared it by phone to the Head of IT five minutes before signing in.

    In the pack

  5. Step

    Open the safe with two people and sign in

    The password and security key are sealed in numbered tamper-evident envelopes in the safe, with a second set at a second site, and opening the safe takes two people, by the pack's default. Check the envelope numbers: a broken or renumbered envelope is a finding. Keep the opened envelope, because it goes with the record after the reseal.

    In the pack

  6. Decision

    Did the sign-in alert reach the named people?

    Every sign-in alerts the Head of IT and the Head of Information Security at once, by email and text message, by the pack's default. Confirm they received it. The alert is what makes an undeclared use visible, so one that did not fire is a fault in the control itself. Not known counts as no.

    In the pack

  7. Step

    Raise the missing alert as a finding of its own

    An alert that did not fire is a finding of its own, separate from the use. Tell the named people directly, so the use still reaches them, and have the alert fixed: the account's checks pass only if the alert fired at its last test. The session review's break-glass question looks for exactly this case.

    In the pack

  8. Step

    Do only what brings the normal route back

    Every action the account takes is reviewed afterwards against the declared reason, from a log the account cannot change. Keep to the fix that restores the normal route. In the pack's example, the engineer rolled back the faulty sign-in policy, changed nothing else, and signed out.

    In the pack

  9. Step

    Have the Head of Information Security review every action

    Within 1 working day by the pack's default, the Head of Information Security reviews every action the account took against the stated reason, from the log the account cannot change. Name this reviewer before any use happens. In the pack's example, the review was 14 working days late because the Head of IT and the IT provider each thought the other would do it.

    In the pack

  10. Decision

    Does every action match the declared reason?

    Compare each action in the log with the reason given: what changed, on which system, and when. A use with nothing outside the reason is the expected result. Not sure counts as no.

    In the pack

  11. Step

    Record each unmatched action and ask for an explanation

    Record each action the reason does not cover as an anomaly: the account, system and time, what the reason covered and what the log shows. As the session review does for an elevation outside its ticket, the person who used the account explains it in writing, and the reviewer agrees a follow-up with an owner and a date.

    In the pack

  12. Decision

    Is there any sign of misuse or compromise?

    An action outside the reason that is explained is a finding about how the account was used. An action nobody can explain, a change to logging, or a sign-in nobody declared is a sign the account may be in the wrong hands. If you are not sure, the incident triage procedure treats not sure as yes.

    In the pack

  13. Outcome

    Contain it and report a security incident

    Contain at once and report it as a security incident; the Head of Information Security is told at once. The incident does not wait for the review to finish. On suspicion of compromise the credential is changed at once, not within the usual working day, and resealed. Misuse of privileged access is an incident in the pack's own terms.

    In the pack

    See also

  14. Step

    Change the password and key, and reseal them

    Within 1 working day by the pack's default, change the password, register a new security key where one was used, and seal both in new numbered envelopes. Keep the old envelope with the record. A test that opens the seal needs the same change and reseal.

    In the pack

  15. Decision

    Were the review and the reset both done within 1 working day?

    The pack counts a use as on time only if it was declared, reviewed by the Head of Information Security and followed by a credential change, each in time. That is its measure of break-glass uses reviewed on time, and its tolerance is every use: one late review puts it outside tolerance. Not known counts as no.

    In the pack

  16. Step

    Finish the late step and report the measure outside tolerance

    Do the missing review or reset now; doing it late does not make the use on time. A measure outside tolerance goes to the next executive committee with its plan. Fix the cause of the delay too: in the pack's example, the fix was to name the Head of Information Security as the reviewer of every use in the checklist.

    In the pack

  17. Outcome

    Fix the cause and close the record with the reviewer's name

    The record closes only when the cause is fixed so the normal route works again, and it carries the reviewer's name. Run the ten break-glass account checks again, as the standard sets them at every test and after every use. In the pack's example, the faulty policy change was tested again before it was re-applied.

    In the pack

Practical checklist

  1. Confirm the normal administration route itself is unavailable. If it is only slow, use an ordinary or out-of-hours elevation.
  2. Declare the use and its reason to the Head of IT, or the Head of Information Security if the Head of IT is unavailable, before signing in or at once after.
  3. Open the safe with two people, check the envelope numbers, and sign in.
  4. Confirm the sign-in alert reached the named people. Raise a missing alert as a finding of its own.
  5. Do only what brings the normal route back.
  6. Have the Head of Information Security review every action against the reason, from the log the account cannot change, within 1 working day.
  7. Change the password, register a new security key where one was used, and reseal both within 1 working day.
  8. Fix the cause, run the break-glass account checks again, and close the record with the reviewer's name.

Evidence to have ready

  • The use record: who used which account, why the normal route was unavailable, when it started and ended, and when and to whom it was declared.
  • The time the alert was received, or the finding raised because it did not fire.
  • The session review against the declared reason, with the reviewer's name and date, and each unmatched action with its explanation and follow-up.
  • The date the credential was changed and resealed, with the old envelope kept with the record.
  • The break-glass account checks run after the use, and the incident reference if compromise was suspected.

Assumptions

  • Break-glass accounts exist as the pack sets them: 2 for each cloud identity tenant and 1 for each on-premises directory, sealed in a two-person safe, alerting on every sign-in, and tested every 3 months.
  • A Head of IT and a Head of Information Security, or your equivalents, are named to receive declarations and alerts, and the reviewer of every use is named in advance.
  • The 1-working-day review and reset are the CISO Times privileged access pack's defaults. Your own standard may set others.

Not covered here