If an administrator uses their admin account for email or browsing, then what?

Start

An admin account was used for email, browsing or another tier

An administrator account must have no mailbox, must never be used for email or web browsing, and signs in only from an administration device of its tier. Used for email or browsing, or outside its tier, it is treated as a possible exposure of its credential. The same steps run whether a session review, an alert or the person themselves found it.

• Then: Stop the use and end the account's sessions at once

Step

Stop the use and end the account's sessions at once

The first step is at once, whoever found it: stop the use and end every session the account holds. The deadlines that follow run from the day the breach was found. In the pack's example, the weekly review found a breach two working days after it happened: the review cadence is the detection time.

• Then: Tell the Head of IT and Head of Information Security today

Step

Tell the Head of IT and Head of Information Security today

A tier breach goes to the Head of IT and the Head of Information Security the same day, and the procedure's steps start at once. The session reviewer records it as an anomaly: the account, the system and the time, what was approved and what the logs show.

• Then: Is anything still happening that the administrator did not do?

Decision

Is anything still happening that the administrator did not do?

Look at the account's current sessions and recent sign-ins: a session still open somewhere, a sign-in the administrator does not recognise, or a change they did not make. The incident triage procedure sends anything still happening straight to the incident manager. Not sure counts as yes.

• Yes, or not sure: Report a security incident and keep the breach steps going
• No: Is it a Tier 0 account?

Decision

Is it a Tier 0 account?

Tier 0 controls the directory, the cloud identity tenant, the backups and device management. One stolen Tier 0 credential is a compromise of the whole estate, so its password changes at once. An account holding Tier 0 rights alongside others counts as Tier 0. Not known counts as yes.

• Yes, or not known: Change the password and revoke tokens at once
• No: Change the password and revoke tokens within 1 working day

Step

Change the password and revoke tokens at once

Change the account's password and revoke its sessions and tokens at once. A new password alone leaves a captured session token working, which is why tokens are revoked too. In the pack's example, a Tier 0 account found signed in to a file server had its password changed and its sessions ended the day the review found it.

• Then: What did the account touch?

Step

Change the password and revoke tokens within 1 working day

For a Tier 1 or Tier 2 account, change the password and revoke its sessions and tokens within 1 working day by the pack's default. The sessions already ended in the first step; this step makes anything captured with the credential useless.

• Then: What did the account touch?

Decision

What did the account touch?

The check depends on where the credential went. A mailbox or website is where phishing and malicious downloads land. A lower-tier system may already be in an attacker's hands, and a credential typed into it can be captured there. If it touched both, check both.

• Email or the web: Check what it received, opened or downloaded
• A system of another tier: Check the lower-tier system it signed in to

Step

Check what it received, opened or downloaded

Within 1 working day, check the mailbox or browsing it touched for signs of compromise, such as messages opened, links followed, files downloaded and anything that ran. If the account has a mailbox or an office licence at all, remove it: an administrator account should have neither.

• Then: Review everything the account did since the breach

Step

Check the lower-tier system it signed in to

Within 1 working day, check the system it touched for signs of compromise. A higher-tier credential on a lower-tier system could have been captured by anyone who controls that system. In the pack's example, the Information Security Manager checked the file server the next day and found no sign of compromise.

• Then: Review everything the account did since the breach

Step

Review everything the account did since the breach

Within 1 working day, review what the account did from the breach onward. Where the review finds something, widen it to every event of the same account in the period. The reviewer holds no administrator rights in the account's tier.

• Then: Is there any sign of compromise or misuse?

Decision

Is there any sign of compromise or misuse?

If the mailbox, site or system it touched shows any sign of compromise, the pack makes it an incident under the incident management pack. Misuse of privileged access is an incident too. If you are not sure, the incident triage procedure treats not sure as yes.

• Yes, or not sure: Report a security incident and keep the breach steps going
• No: Fix the cause within 1 month

Outcome

Report a security incident and keep the breach steps going

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 breach steps, and the breach steps do not stop for the incident: the password change, the review and the fix within 1 month still happen. The administrator's own activity is preserved and reviewed by someone else before they take part in the investigation.

Step

Fix the cause within 1 month

Give the person an account of the right tier, and a policy that blocks the same sign-in next time: group policy denying higher-tier groups sign-in on lower-tier systems, no mailbox or licence on administrator accounts, and an administration device with browsing limited to administration portals. In the pack's example, an account holding two tiers' rights was split into a Tier 0 and a Tier 1 account.

• Then: Should a policy have blocked it, or has it happened before?

Decision

Should a policy have blocked it, or has it happened before?

If a policy should have stopped the sign-in and did not, the breach is also a finding: the control failed. The same anomaly in two reviews running is a finding too, reported to the Head of Information Security in the monthly report. Not known counts as yes.

• Yes, or not known: Raise a finding with an owner and a date for each fix
• No: Record it in the session review and close the steps

Outcome

Raise a finding with an owner and a date for each fix

Raise it as a finding in your control review, with one action, an owner and a due date for each fix, and close it when every action is done. The control review's tier test passes only when no account of another tier has signed in to the system in the last 30 days.

Outcome

Record it in the session review and close the steps

Record the breach in your session review record, with the steps taken and their dates, in the next review at the latest. Close it when every step is done. Until the fix is in place, check the account by name in each session review, as the pack's example does.