How do we control administrator access without a PAM platform?

Start

Control administrator access with the tools you have

Privileged accounts are what an attacker looks for first, because one is worth more than every ordinary account together. The pack's rules make a privileged credential hard to steal, short-lived when in use, and useless where it is most likely to be captured. Each one can be built from the directory, group policy, the identity provider, a business password manager and a central log store. A platform automates the vault, the time limits and session recording; it is not a precondition.

• Then: List every privileged account and give each an owner

Step

List every privileged account and give each an owner

Build the list from each system's own records: administrator groups and roles, accounts whose password never expires, accounts that run a service or task, built-in administrators and supplier accounts. Record each one's owner, tier, purpose, where its credential is kept and when it last changed. An account found that nobody claims within 5 working days is disabled.

• Then: Give every system a tier

Step

Give every system a tier

Tier 0 is the identity and control plane: the directory, the cloud identity tenant, the backup and device management consoles, the vault and whatever hosts them. Tier 1 is servers, applications and cloud workloads; Tier 2 is end-user devices and user support. A system takes the tier of the most important thing it can control. A system without a tier has no separation rule, and that is where tier breaches happen.

• Then: Give each administrator a separate account per tier

Step

Give each administrator a separate account per tier

Create a second account per person per tier in the directory, named by tier (for example a0-, a1-, a2-), with no mailbox and no office licence. Remove every daily account from local and directory administrator groups through device management or group policy. Support uses the local administrator password solution instead, which gives each device its own password, changed after use, with every opening logged.

• Then: Does any account hold rights in more than one tier?

Decision

Does any account hold rights in more than one tier?

An account belongs to one tier and administers only that tier; a person who works in two tiers holds one account for each. An account that spans tiers carries its highest-tier credential onto lower-tier systems. In the pack's example, one account held Tier 0 backup rights and Tier 1 server rights, and signed in to a file server while its Tier 0 elevation was active.

• Yes, or not known: Split it into one account per tier
• No: Deny higher-tier accounts sign-in on lower-tier systems

Step

Split it into one account per tier

Give the person a separate account for each tier, and move each right to the account of its tier. The inventory's checks flag each account it lists that spans tiers. Until an account is split, the pack's example checks it by name in each weekly session review.

• Then: Deny higher-tier accounts sign-in on lower-tier systems

Step

Deny higher-tier accounts sign-in on lower-tier systems

Use group policy to deny sign-in by higher-tier administrator groups on lower-tier systems, for console, Remote Desktop, batch and service logon, and add Tier 0 accounts to the directory's protected users group. Administrators work from an administration device of their tier: a dedicated workstation, a hardened jump host reached from one, or at the least a hardened virtual machine with no email and browsing limited to administration portals.

• Then: Require security keys or passkeys for administrator accounts

Step

Require security keys or passkeys for administrator accounts

Register security keys or passkeys in the identity provider you already have, and require them for administrator accounts by sign-in policy. Text message codes, app codes and push approvals are not accepted for any privileged account. An application that offers neither single sign-on nor such a method uses the strongest it has, recorded in the inventory with the date it will move.

• Then: Can the directory or tenant time-limit group or role membership?

Decision

Can the directory or tenant time-limit group or role membership?

Rights in Tier 0 and Tier 1 must be just-in-time: eligible, switched on for one task, and ended by the system after no more than 4 hours in Tier 0 and 8 hours in Tier 1. Most directories offer time-limited group membership, and cloud tenants offer time-limited role assignment where the licence includes it. Not known counts as no until you have tested that a right really ends.

• Yes: Make Tier 0 and Tier 1 rights eligible, ending by themselves
• No, or not known: Add rights by ticket, with a scheduled task to remove them

Step

Make Tier 0 and Tier 1 rights eligible, ending by themselves

Remove standing membership of the Tier 0 and Tier 1 groups and roles, and make each one eligible, with the tier's maximum configured. The rights end at the earlier of the approved end and the tier's maximum, switched off by the system, never by someone remembering. An unfinished task needs a new approval; the window is never extended on the same ticket.

• Then: Does anyone still hold standing Tier 0 or Tier 1 rights?

Step

Add rights by ticket, with a scheduled task to remove them

Where the directory cannot time-limit a membership, add the right by ticket with an end time. A scheduled task removes it at that time, and a daily report lists any right older than its ticket, so a failed removal shows the next day. The report alone is not enough: noticing an expired right is not the same as ending it.

• Then: Does anyone still hold standing Tier 0 or Tier 1 rights?

Decision

Does anyone still hold standing Tier 0 or Tier 1 rights?

Standing rights are allowed only for break-glass and service accounts, Tier 2 support on separate Tier 2 accounts, read-only monitoring, and application roles the application cannot assign for a time, each recorded in the inventory. Any other standing right is a departure from the standard. Check the directory and tenant themselves, since the inventory only flags the accounts it lists.

• Yes, or not known: Move them, or cover them with a dated plan or an exception
• No: Keep shared, service and break-glass credentials in a vault

Step

Move them, or cover them with a dated plan or an exception

A rule adopted with a later start date on an approved plan is a transition, not an exception, while the plan holds; if the plan slips, it becomes an exception that day. Anything a plan does not cover is an exception, approved by the approver its band sets. In the pack's example, a managed IT provider's two engineers kept standing server rights between windows under a Medium exception, approved by the Head of Information Security until Tier 1 moves to just-in-time.

• Then: Keep shared, service and break-glass credentials in a vault

Step

Keep shared, service and break-glass credentials in a vault

Use the organisation's business password manager, in a shared vault open only to named administrators, with its access log kept. Break-glass credentials are also sealed in a safe. Each credential changes as the rotation table sets: a shared account in the vault at least every 3 months and after every use, and any credential at once on suspicion of compromise.

• Then: Send privileged events where administrators cannot change them

Step

Send privileged events where administrators cannot change them

Forward the directory's security events, the cloud tenant's audit and sign-in logs and servers' administrator command logs to a central log store, such as one your monitoring provider keeps. Every privileged sign-in, elevation, change to a privileged group or role, and vault opening is kept there for at least 12 months. The pack's control test looks for a test event in the store.

• Then: Can any administrator change or delete those records?

Decision

Can any administrator change or delete those records?

The people whose actions are checked must not control the record of them: administering a system and reviewing its audit logs is a High conflict in the segregation-of-duties matrix. If the only administrator also runs the log store, the records prove nothing. Not known counts as yes.

• Yes, or not known: Move the records out of the administrators' reach
• No: Is someone with no administrator rights in the tier free to review?

Step

Move the records out of the administrators' reach

Send them to a store run by someone else, such as your security monitoring provider, and give the administrators no right to change or delete there. Then check that privileged events still arrive. Where one person runs all of IT, the logs are only half the answer; the independent review below is the other half.

• Then: Is someone with no administrator rights in the tier free to review?

Decision

Is someone with no administrator rights in the tier free to review?

Session reviews and the control review are done by someone with no administrator rights in the tier reviewed. In a small IT team the Head of IT may be the only Tier 0 administrator, so their own elevations are approved by the Head of Information Security and their sessions reviewed by someone with no Tier 0 rights. Not known counts as no.

• Yes: Review sessions and controls at the pack's cadence
• No, or not known: Use an outside reviewer and record it as an exception

Step

Use an outside reviewer and record it as an exception

Where nobody inside qualifies, the pack suggests your security monitoring provider, an outside adviser, the internal auditor or a peer from another organisation, who does the review and signs the record. It records the arrangement as an exception, so it is approved and expires rather than becoming a habit. A provider never reviews its own engineers' sessions.

• Then: Review sessions and controls at the pack's cadence

Outcome

Review sessions and controls at the pack's cadence

Tier 0 activity is reviewed weekly, every event, within 2 working days; Tier 1 monthly, every event without a ticket plus a sample; Tier 2 quarterly by sample; supplier sessions monthly; every break-glass use within 1 working day. The system owner and information security review privileged access every 3 months, and the controls are tested system by system yearly, every 6 months for Tier 0.