PCI DSS Service Account Requirements: A Breakdown

Historically, PCI DSS has treated most service accounts as shared administrator accounts that had to be authorized with specific privileges using strong authentication factors. But now, version 4.0 of the PCI DSS has greatly expanded the scope of authentication and authorization requirements—while you’ll still need to secure those administrator accounts, you’ll now also need to implement controls to protect any application and service accounts in your environment.

As experienced PCI Quality Security Assessors, we’ve gone through the new version 4.0 extensively, having broken down several important aspects to help facilitate an easier changeover for organizations, and what follows is more of the same.

In this comprehensive blog post, we’ll first define what a service/application account is before breaking down the new relevant requirements in PCI DSS v4.0 and providing implementation guidance so that you adjust to maintain compliance that much easier.

What is PCI DSS’s Definition of a Service/Application Account?

By definition, a service account is a computer account intended for a software application to interact with another application. Technically, a service account is specific to a service on an operating system while an application account is specific to a database or other application, but for PCI DSS purposes, both count as “service accounts.”

As simple as that definition may seem, identifying these accounts isn’t always straightforward, though in most cases, the naming convention is a good giveaway—human user accounts typically follow the $FIRSTNAME.$LASTNAME naming convention, while a service account is often named after the service or application using it.

What makes this more complicated is the fact that the PCI DSS has a few requirements that apply only to service accounts that could be used for interactive login—“could” being the operative word, because if a human can interact with the system using that service account, then the requirements apply.

What are the PCI DSS Service Account Requirements?

Let’s dig more into the requirements—there are some that apply directly to service accounts with interactive logins, and some that apply to all service accounts regardless of login characteristics.

PCI DSS Requirements for Services Accounts with Interactive Logins

PCI DSS Requirements 8.2.2 and 8.6.1 - For Interactive Logins ONLY

IMPLEMENTATION GUIDANCE:

Because—by default—a service account is a generic account with shared authentication credentials, these requirements are very similar. So, it would make sense to satisfy them together, particularly because we can address them with two broad controls—you can see where we’ve done that in orange and green.

Address those in green first, as they’re more important in that they ensure that any interactive use of a service account is logged, which goes hand in hand with PCI requirement 10.2.1.2 (“Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts”).

Once you have that mechanism in place, you can be assured that any use of that service account, whether authorized or not, will be captured. That also means that the rest of the particulars—those in orange—just require the implementation of a process for authorizing the interactive use of the service account, and you can address this by creating a ticket or incident that includes all the relevant information.

PCI DSS Requirement 8.6.2 - For Interactive Logins ONLY

IMPLEMENTATION GUIDANCE:

Of the ones we address in this post, this will probably be the trickiest control to implement.

If you’ve taken the common approach of including database connection strings that include credentials in a .env file, Kubernetes secret object, or some other method, the good news is that this is still acceptable for service accounts without the interactive login privilege. However, you’ll need to find another way to handle secrets for interactive service accounts, and the most obvious answer to that is to use a secret vault and inject the secret at runtime. Whether you use a key vault or something else to store the credentials, you’ll need to ensure that any access can be traced back to an individual user.

PCI DSS Requirement 11.3.1.2.c - For Interactive Logins ONLY

 IMPLEMENTATION GUIDANCE:

If you make the necessary implementations to meet the aforementioned requirement 8.2.2, that should also cover this—there’s nothing much to add.

PCI DSS Requirements for All Services Accounts
(Regardless of Interactive Login Privileges)

PCI DSS Requirement 7.2.5

 IMPLEMENTATION GUIDANCE:

According to PCI DSS v4.0, service accounts should only be available to the applications that need them and should only include the specific privileges they need to operate. To satisfy this, simply extend the same role-based access controls and least-privilege principles that have been required for human administrator accounts to service accounts.

PCI DSS Requirement 7.2.5.1

 IMPLEMENTATION GUIDANCE:

To meet this requirement, you must periodically review and confirm that all service accounts still have the appropriate scope and permissions.

While the PCI council recommends conducting this review every six months, your frequency will be ultimately determined by the results of a targeted risk analysis (TRA). If you decide to track these reviews in a recurring ticket, keep in mind that you’ll need to provide some kind of audit artifact to prove that the review occurred and was signed off on by management. (Who constitutes “management” is defined by each organization.)

PCI DSS Requirement 8.6.3

IMPLEMENTATION GUIDANCE:

All service account credentials must now be rotated on a schedule. And again, while the PCI council recommends doing this every three months, your organization’s specific risks will determine what your frequency will be.

Your TRA will help you determine how frequently to rotate service account credentials but don’t forget that you must also specify the credential length and complexity requirements. While this likely won’t be an issue for most organizations—as API keys and/or service account credentials are typically very long and complex given that a human does not need to enter them—you’ll still need to ensure that the requirements are specifically called out in a document somewhere.

We should also note that the applicability of this requirement is not contingent upon the ability to interactively use service accounts—Requirement 8.6.3 must be met even when there are no service accounts that do not allow interactive login.

Moving Forward with PCI DSS v4.0

PCI DSS v4.0 has introduced many critical changes to the flagship payment card standard, including these regarding the requirements for service accounts. Now that you understand more about the requirements, you’re better positioned to make the needed implementations to satisfy them, but which accounts should you target with your changes?

To help with your determinations, we’ve written a separate blog post on how to identify service accounts in different operating systems that should streamline your search. In the meantime, make sure you check out our entire library of articles breaking down different aspects of PCI DSS v4.0 that can help clarify the many new updates to the framework.