Remember your Service Accounts - WST

Most organizations have some type of onboarding/offboarding process they use when handling staff changes. When a new person joins the team, there’s a process for getting that new person’s user account made, put in the right security groups, email assigned, and so on. A similar process happens when someone moves on – the person’s account gets disabled (and eventually deleted), resources may get new permissions assigned, mailbox access may change, and so on. It’s User Management 101.

Many applications and back-end services also require accounts to be created for the application or service to function. These types of accounts are generally called “service accounts,” and they also need to be managed – but all too often, we see that service accounts do receive the same level of care as normal user accounts.

There is risk here: many times, we see service accounts in Domain Admin groups or other high-level privileged access groups. Proper management of these accounts helps reduce the risk of high-powered accounts being used maliciously.

Here are a few tips for service account management:

1. Document why you created the account. When creating a service account in Active Directory, use the description field on the account to document when it was created and what it’s used for.
2. Include service accounts as part of your periodic user review processes and maintain an inventory of those accounts. Be aware that you may need to get technical resources available to help decipher which service accounts are used by which applications. You may also need to get application vendors involved. Once you have an understanding of a service account, capture the purpose of the account, applications that use the account, departments that use that application, and the last review date.
3. Service accounts also require password management. Ensure that service account passwords are very long, complex, and securely documented. This can shorten recovery time if there is a problem with a service account.
4. Review the group membership of your service accounts. Confer with your technical resources and vendor technical support to determine if the level of access assigned to each service account is appropriate. Remember that the principle of least privilege should always apply. Also, be aware that admin privileges might have been required during initial install of an application but may not be required after installation. As always, TEST before making any changes to group membership for any service accounts.
5. Add service account management to any application/service onboarding and offboarding processes. If a new application requires a service account, capture that account early in the process. If an application is going by the wayside, disable any service account used by the application as part of the decommissioning process, and then delete that account once decommissioning is complete. One important caveat here! Before disabling a service account, ensure that account is ONLY being used by the app or service being removed – it is possible that other services may be using that account as well. Get technical help as needed, and again, TEST before making any changes.
6. Include service accounts in any anomalous activity monitoring and detection processes. Best practice is to have automated processes scanning for suspicious activity and alerting appropriate staff when things do not look right. Knowing your service accounts helps you better understand what “normal” activity looks like.

Malicious actors can and do attempt to use service accounts when attacking – take some time to care for these accounts too!

Authored by: David Bentley, CISSP, August 26th, 2021