Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we find and control service accounts nobody owns?

5 decision pointsThe pack behind this answer: Privileged Access Management

Add to board memo

The short answer

Recommendation
Match every account whose password never expires, that runs a service or task, or that sits in an administrator group against your privileged account inventory. Give each unowned one an interim owner within 5 working days or disable it, then put it under control at once.
Reasoning
An account nobody owns is the one an attacker uses: nobody notices its sign-ins and nobody changes its password. Every service account needs a named owner, one job with the least rights it needs, and no interactive logon (PA-11). The interim owner controls it from the day they take it, because the 30-day limit for a permanent owner is not permission to leave it uncontrolled. Anyone still signing in with it gets a named account first, so support does not stop.
Considerations
  • The 5 working days, 30 days and 90 days are the pack's defaults. Your own standard may set others.
  • A service account's owner is a named person, never a team or a supplier. The IT Operations Manager, or your equivalent, owns service accounts that no business owner claims.
  • If its sign-ins show signs of compromise, or you cannot tell, contain it and report a security incident. Export its sign-in log before resetting it, and change the credential at once.
  • A supplier's engineers who used the account get named accounts, enabled only for approved windows. Shared supplier accounts are not allowed (PA-15).

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome
StartLook for service accounts nobody ownsStepList service-like accounts and compare them with the inventoryDecisionIs it in the inventory with a named person as its owner?OutcomeLeave it with its owner and test it at the control reviewDecisionDo its sign-ins show signs of misuse or compromise?OutcomeContain it and report it as a security incidentDecisionHas an interim owner taken it within 5 working days?OutcomeDisable it and note the dateStepHave the interim owner control it while dependencies are checkedDecisionHave people been signing in with it?StepGive those people named accounts firstStepDeny the account interactive logon by policyStepChange its credential into the vault or a managed accountStepCut its rights to one job in one tierDecisionIs a permanent owner confirmed within 30 days?OutcomeDisable it, and delete it 90 days later if nothing breaksOutcomeRecord its owner, and alert on any interactive sign-in

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

    Look for service accounts nobody owns

    Every service account must have a named owner, do one job with the least rights it needs, and be unable to sign in interactively. An account nobody owns is the one an attacker uses: nobody notices its sign-ins and nobody changes its password. In the pack's example, a warehouse database service account had local administrator rights, a password unchanged since the system was installed in 2019, and supplier staff signing in with it.

    In the pack

  2. Step

    List service-like accounts and compare them with the inventory

    From each server and the directory, list every account whose password never expires, that runs a service or scheduled task, or that sits in an administrator group. Match the list against the inventory, and note each account found outside it on the day it is found, with what it can do. The control review's first test makes the same match, system by system.

    In the pack

  3. Decision

    Is it in the inventory with a named person as its owner?

    A service account's owner is a named person, never a team or a supplier, so an owner recorded as a team or as the supplier that installed the system does not count. Not known counts as no.

    In the pack

  4. Outcome

    Leave it with its owner and test it at the control review

    The control review tests each service account system by system: it passes only if the account has an owner, a policy denies it interactive logon, and it made no interactive sign-in in the last 30 days. Tier 0 systems are tested every 6 months and the rest every 12 months, by the pack's default.

    In the pack

  5. Decision

    Do its sign-ins show signs of misuse or compromise?

    Read its recent sign-ins before changing anything: interactive sign-ins, sign-ins from unexpected places, or use outside its job. A review that finds signs an account may be compromised contains it at once and reports an incident, and the review continues alongside. If you cannot tell, the incident triage procedure treats not sure as yes.

    In the pack

  6. Outcome

    Contain it and report it as a security incident

    Report it under your incident procedure, and contain at once: a shared or service credential is changed at once on suspicion of compromise, and its sessions ended. Keep its logs before anything is cleaned up. The ownership and control steps in this flow still apply to the account afterwards.

    In the pack

    See also

  7. Decision

    Has an interim owner taken it within 5 working days?

    Ask the system owners and the suppliers what runs under it. An account found outside the inventory is disabled unless someone claims it within 5 working days, by the pack's default; for a service account, the claim is an interim owner who controls it while its dependencies are checked. The IT Operations Manager owns service accounts that no business owner claims.

    In the pack

  8. Outcome

    Disable it and note the date

    An unclaimed account is disabled, not left running while the search goes on. Note when it was disabled, and watch for what fails: whoever runs the failing service is the owner to name. The pack does not say how to restore a service that fails; your change process decides that.

    In the pack

  9. Step

    Have the interim owner control it while dependencies are checked

    The interim owner answers for the account from the day they take it. The 30-day limit for a permanent owner is not permission to leave it uncontrolled, so the controls that follow start now. In the pack's example, the IT Operations Manager was named the day after the account was found.

    In the pack

  10. Decision

    Have people been signing in with it?

    Check its interactive sign-ins: at the console, by Remote Desktop, or through a remote support tool. In the pack's example, a supplier's support staff signed in with the service account, whose password sat in their support notes. Not known counts as yes, because denying logon would cut off anyone who still relies on it.

    In the pack

  11. Step

    Give those people named accounts first

    Each person who used it gets a named account of the right tier. A supplier's engineers get named accounts enabled only for approved windows, because shared supplier accounts are not allowed. Deny the service account's interactive logon only once they have them, so support does not stop: the pack's example orders it that way.

    In the pack

  12. Step

    Deny the account interactive logon by policy

    Deny console, Remote Desktop and remote support sign-in for the account by group policy. A service account runs software and never needs to sign in as a person. Every session review then asks whether any service account signed in interactively.

    In the pack

  13. Step

    Change its credential into the vault or a managed account

    Move it to a managed service account where the platform allows: the platform then changes the password itself, at least every 30 days. Otherwise change the password in a planned change window, put it in the vault, and change it at least every 12 months. Anyone who knew the old password, such as a supplier with it in their notes, loses that access with the change.

    In the pack

  14. Step

    Cut its rights to one job in one tier

    Take it out of every group it does not need for its one job. A service account takes the tier of the most important system it can change and runs only on systems of that tier, so take it out of any tier above the systems it runs on. Each right it keeps but does not use is a right an attacker can use.

    In the pack

  15. Decision

    Is a permanent owner confirmed within 30 days?

    The interim owner and the system owner confirm what runs under the account and who answers for it. By the pack's default, a service account with no owner found within 30 days is disabled, with the date. Not known counts as no.

    In the pack

  16. Outcome

    Disable it, and delete it 90 days later if nothing breaks

    Disable it and note the date. If nothing breaks in the 90 days that follow, delete it and mark it removed in the inventory, keeping the row. If something does break, the service that failed shows who should own it.

    In the pack

  17. Outcome

    Record its owner, and alert on any interactive sign-in

    Record its owner, tier, purpose, credential location and last change in your inventory. An alert on any interactive sign-in by a service account goes to the session reviewer, and each session review asks whether one happened. The control review tests the account again at its next cycle.

    In the pack

Practical checklist

  1. List every account whose password never expires, that runs a service or scheduled task, or that sits in an administrator group, and match the list against the inventory.
  2. Read each unowned account's recent sign-ins, and report an incident if there are signs of compromise or you cannot tell.
  3. Ask the system owners and suppliers what runs under it. Name an interim owner within 5 working days, or disable it.
  4. Give named accounts to anyone who has been signing in with it, then deny its console, Remote Desktop and remote support sign-in by policy.
  5. Move it to a managed service account, or change its password in a planned change window and put it in the vault.
  6. Take it out of every group it does not need, and out of any tier above the systems it runs on (SR-5).
  7. Confirm a permanent owner within 30 days, or disable it and delete it 90 days later if nothing breaks.
  8. Alert the session reviewer on any interactive sign-in by a service account.

Evidence to have ready

  • The dated list of accounts found, matched to the inventory, with the date each was found and what it can do.
  • For each service account, its owner, its rights and the policy denying interactive logon.
  • The date any unowned account was disabled, and the date it was deleted.
  • The vault entry or managed account for each service credential, with its last change.
  • 30 days of each service account's sign-ins, and the session reviews that asked whether any signed in interactively.

Assumptions

  • You can list, from each server and the directory, the accounts with passwords that never expire, the accounts that run services or scheduled tasks, and the members of administrator groups, and compare them with an inventory of privileged accounts.
  • System owners, the IT Operations Manager or your equivalent, and your suppliers can be asked what runs under each account.
  • The 5-working-day, 30-day and 90-day limits are the CISO Times privileged access pack's defaults. Your own standard may set others.

Not covered here