Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we review privileged and administrator access?

5 decision pointsThe pack behind this answer: User Access Review

Add to board memo

The short answer

Recommendation
Review privileged and administrator access on every system every 3 months in the pack's defaults. The system owner and information security both review each membership, nobody reviews a group they belong to, and every privileged account needs a named person who answers for it.
Reasoning
Privileged access can change a system, its users or its security, so it can do the most harm. A small list is not a small risk: an administrator account nobody owns is exactly what an attacker looks for. Each membership is tested in turn: is there a current holder, has it been used, does the job need every right, and does a named person answer for it. A Keep without an owner is not a decision.
Considerations
  • The 3-month frequency, the 90-day unused threshold and the 1 working day removal window are the pack's defaults. Your own method may set others.
  • An unused account stays only with the system owner's recorded reason. For an emergency account, the segregation-of-duties pack adds conditions: named in advance, every use logged and alerted to someone else, the log reviewed by someone else, and credentials changed after use.
  • Where the system owner is in the group, their membership goes to a named executive outside it. In a small organisation, an executive or an external adviser reviews the administrator accounts with the IT manager.
  • Access hidden in a nested group, a local account or an API key is never reviewed if the extract does not show it.

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartReviewing administrator groups and privileged rolesStepExtract every privileged group, with nested groups expandedStepHave the system owner and information security review each oneDecisionIs a reviewer a member of the group they are reviewing?StepSend that membership to someone outside the groupDecisionDoes the account belong to a current person or named owner?DecisionHas it signed in within the last 90 days?StepKeep it only with the system owner's recorded reasonDecisionDoes the current job need every privileged right it holds?StepModify it down to the rights the job needsDecisionDoes a named person answer for the account?StepHold it as Cannot decide until the system owner names oneStepRevoke it and raise a findingOutcomeRemove within 1 working day, then confirm on a fresh extractOutcomeKeep, with both reviewers' names and dates

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. 15 steps.

  1. Start

    Reviewing administrator groups and privileged roles

    Privileged access can change a system, its settings, its users or its security. It can do the most harm and changes most often, so it is reviewed every 3 months on every system. A small list is not a small risk: fourteen entries reviewed properly each quarter protect more than a hundred reviewed carelessly once a year.

    In the pack

    See also

  2. Step

    Extract every privileged group, with nested groups expanded

    List the membership of every administrator group and privileged role, with nested groups expanded to named people, last sign-in for each account, and service accounts with their owners. Check the count matches the system's own. Access hidden in a nested group, a local account or an API key is never reviewed if the extract does not show it.

    In the pack

  3. Step

    Have the system owner and information security review each one

    Both review every privileged membership, with both names and dates recorded. Privileged entries are decided by the deadline; they are not left for the escalation ladder, because the system owner is already their reviewer.

    In the pack

  4. Decision

    Is a reviewer a member of the group they are reviewing?

    An administrator never reviews the administrator group they belong to. This includes shared administrator accounts they use but that are not in their name. If you cannot tell, check before the lists go out.

    In the pack

  5. Step

    Send that membership to someone outside the group

    In the pack's example, the Head of IT's own membership goes to the Head of Information Security. Where the system owner is in the group, their membership goes to a named executive outside it. In a small organisation where the IT manager administers everything, an executive or an external adviser reviews the administrator accounts with them.

    In the pack

    See also

  6. Decision

    Does the account belong to a current person or named owner?

    A leaver's administrator account, or one nobody can be matched to, fails here. An administrator account nobody owns is exactly what an attacker looks for.

    In the pack

  7. Decision

    Has it signed in within the last 90 days?

    An unused account is revoked and raised as a finding, unless the system owner records why it must stay. The pack's example of such an account is an emergency ('break-glass') account, which by design is rarely used.

    In the pack

  8. Step

    Keep it only with the system owner's recorded reason

    The system owner records why the unused account must stay. For an emergency account, the segregation-of-duties pack adds conditions: named in advance, every use logged and alerted to someone other than the user, the log reviewed by someone else, and credentials changed after each use.

    In the pack

  9. Decision

    Does the current job need every privileged right it holds?

    Least privilege applies to the permission as well as the system. An IT engineer in the domain administrator group who only administers the helpdesk tool needs less. Where the system allows, rights for normal work can be granted for a limited time rather than held permanently.

    In the pack

  10. Step

    Modify it down to the rights the job needs

    Record which right is removed and why. In the pack's example, a service desk lead's role keeps password resets and unlocks, and loses account creation, which belongs to the joiner process. The change is due within 1 working day of the decision date.

    In the pack

  11. Decision

    Does a named person answer for the account?

    Every privileged, generic and service account needs a named owner. For a shared or service account that means someone who knows every use of it. Without one the entry is Cannot decide, never Keep.

    In the pack

  12. Step

    Hold it as Cannot decide until the system owner names one

    The system owner names an owner or the account is revoked. Keeping it without an owner is one of the four rubber-stamp signals the quality check looks for.

    In the pack

  13. Step

    Revoke it and raise a finding

    Leaver, orphan and unused privileged accounts are removed and raised as findings, so the process that left them behind can be fixed. Several on one system point to a process weakness.

    In the pack

    See also

  14. Outcome

    Remove within 1 working day, then confirm on a fresh extract

    Privileged access is removed within 1 working day of the decision date in the pack's defaults. It counts as done only when a fresh extract shows it gone. Report privileged findings and late removals against the risk entry for misuse of privileged access, and say whether its rating still holds.

    In the pack

    See also

  15. Outcome

    Keep, with both reviewers' names and dates

    The account is owned, used and sized to the job. Keep it on record with the system owner's and information security's review. An auditor may pick privileged Keep decisions and ask the named owner why each is needed, so the reason should be one they can give.

    In the pack

    See also

Practical checklist

  1. Extract every privileged group and role with nested groups expanded, last sign-in and service account owners, and reconcile the count.
  2. Have the system owner and information security review every membership by the decision deadline.
  3. Send any membership a reviewer holds, or uses through a shared account, to someone outside the group.
  4. Revoke leaver, orphan and unused accounts, and raise each as a finding (AR-08).
  5. Modify accounts down to the rights the current job needs, recording which right goes and why.
  6. Hold any account without a named owner as Cannot decide until the system owner names one or it is revoked.
  7. Remove privileged access within 1 working day of the decision date, and confirm it on a fresh extract.
  8. Report privileged findings and late removals against the risk entry for misuse of privileged access.

Evidence to have ready

  • The dated extract of privileged groups and roles, with nested groups expanded and the count reconciled.
  • Each privileged decision with both reviewers' names and dates, and the named owner of each account kept.
  • The system owner's recorded reason for every unused account kept.
  • The removal tickets, and the fresh extract confirming each privileged removal within its window.

Assumptions

  • You can list the members of each administrator group or privileged role, with last sign-in, on a stated date.
  • The frequency, removal window and unused-account threshold shown are the defaults in the CISO Times access review pack. Your own method may set different ones.
  • This covers the periodic review only. How privileged access is granted, vaulted or issued just in time is covered only in outline, from the segregation-of-duties pack's conditions for emergency and privileged access.

Not covered here