Are service accounts putting your organization at risk?

In recent months, cyber underwriters have started focusing on the use and vulnerabilities found in service accounts, which are often granted special access to perform a number of essential background tasks on organizations’ networks. With underwriters taking a closer look at these accounts, it’s vital that organizations understand the basics of service accounts, cyber insurers’ views on them and measures they can take to potentially improve risk posture.

What is a service account?

A service account is a generic term for a special type of non-human account used to interact with an application or process in the background. When an application or process is installed or set up, it is common for a service account to be created as well. Some applications create new service accounts specific to their needs, while others reuse existing built-in service accounts.

Service accounts are different from human accounts, which are generally comprised of a username and password used to access a technical resource, such as logging into your work computer, your banking website or email.

Why are service accounts used?

Service accounts are used to interact with an application, process or system in the background. For example, when a user hits “send” on an email, a number of background processes are initiated to ensure the email gets to its destination. These additional processes — such as determining the necessary path to the destination, confirming the accuracy of the email address and scanning the email for viruses — are driven by service accounts.

This process is similar to how physical mail is sent using a nation’s postal service. When people put addressed and stamped mail in the hands of a postal service, they do not always have full clarity into what happens to ensure the mail gets to its destination. But the “service” knows — it happens in the background.

Why are service accounts vulnerable?

The vulnerability of service accounts has come to light in recent years due to their exploitation in cyber incidents.

Service accounts are often considered “fragile” and “untouchable” because they are frequently deeply intertwined with other processes, programs and applications. In some instances, it is not easy to determine and account for which processes, programs and/or applications are relying on a particular service account. Given their broad reach in the greater network environment and the time and cost associated with monitoring each service account, they are frequently overlooked when considering security best practices.

Changing a username or password for a banking website is fairly straightforward; the username and password are only used to access that website. With service accounts, a username and password combination may be used to interact with multiple processes or applications. The passwords for service accounts often are not changed because IT administrators may not know all of the different processes and applications accessed by the account where the password must be changed. They worry that changing the password could lead to unplanned downtime.

Additionally, it is not uncommon for programmers or application developers to build required service accounts with all available access permissions, rather than determining the exact granular permissions necessary. Finally, multifactor authentication (MFA) is not always an option in the traditional sense, as service accounts are not tied to a human user who would input the second part of the authentication.

The combination of lack of password changes, unnecessary access rights and lack of MFA make these accounts prime targets for threat actors seeking free reign over an organization’s network during a compromise.

How are cyber underwriters responding to service accounts?

As a result of these frequent exploitations of service accounts, insurers are taking a much closer look into the volume of service accounts associated with their books of businesses and the privileges granted to those accounts. Insurers consider accounts that are part of an organization’s domain admin group, which contains all accounts with full permissions to perform any task in that environment, to be the most problematic and will deeply scrutinize them.

Mitigating service account risks

To manage potential exposures related to service accounts — and to ease underwriters’ concerns, organizations may consider a number of risk improvement practices. These may include:

  • Frequently auditing the number of service accounts that exist, along with their use and permissions. Among other questions, organizations may ask:

    • How many service accounts do we have?

    • Are all these service accounts still in use?

    • Is there a clear understanding of all programs/applications/system tasks that rely on the service account(s)?

  • Employing password rotation to ensure a regular cadence to password changes and that passwords are complex enough to withstand a typical brute force attack — for example, one where the threat actor makes repeated attempts to enter characters to find the correct password.

  • Denying interactive logon, an account setting in a Windows server environment. This prevents service account usernames and passwords from being used on any typical human login screen via a keyboard and mouse, but will allow accounts to continue to function as required to run necessary background tasks.

  • Auditing privileges and rights by working with a vendor or developer of the software that requires a service account to determine if the service account truly needs privileged/admin access. Many may not need the preset privileged rights.

  • Implementing a Privileged Access Management (PAM) solution to store, protect, and rotate passwords for both user admin accounts and privileged service accounts. As organizations grow, auditing, managing and securing these critical accounts may become daunting. A PAM product may part of the solution to managing this risk. Because a PAM solution is often only accessible with MFA — allowing only for recorded one-time use of a privileged account by a user — it can limit unauthorized use of privileged service accounts.

The contents of this document are for informational and educational purposes only. For any more information on service accounts and their risks, contact (opens a new window).