Schellman becomes The First ISO 42001 ANAB Accredited Certification Body!

Contact Us
Services
Services
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
ESG & Sustainability
ESG & Sustainability
AI Services
AI Services
About Us
About Us
Leadership Team
Leadership Team
Corporate Social Responsibility
Corporate Social Responsibility
Careers
Careers
Strategic Partnerships
Strategic Partnerships

PCI DSS Service Account Requirements: A Breakdown

Payment Card Assessments | PCI DSS

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

8.2.2

Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary, on an exception basis, and are managed as follows:

  • Account use is prevented unless needed for an exceptional circumstance.
  • Use is limited to the time needed for the exceptional circumstance.
  • Business justification for use is documented.
  • Use is explicitly approved by management.
  • Individual user identity is confirmed before access to an account is granted.
  • Every action taken is attributable to an individual user.

8.6.1

If accounts used by systems or applications can be used for interactive login, they are managed as follows:

  • Interactive use is prevented unless needed for an exceptional circumstance.
  • Interactive use is limited to the time needed for the exceptional circumstance.
  • Business justification for interactive use is documented.
  • Interactive use is explicitly approved by management.
  • Individual user identity is confirmed before access to account is granted.
  • Every action taken is attributable to an individual user.

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

8.6.2

Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.

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

11.3.1.2.c

If accounts used for authenticated scanning can be used for interactive login, examine the accounts and interview personnel to verify the accounts are managed following all elements specified in Requirement 8.2.2.

 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

7.2.5

All application and system accounts and related access privileges are assigned and managed as follows:

  • Based on the least privileges necessary for the operability of the system or application.
  • Access is limited to the systems, applications, or processes that specifically require their use.

 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

7.2.5.1

All access by application and system accounts and related access privileges are reviewed as follows:

  • Periodically (at the frequency defined in the entity's targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
  • The application/system access remains appropriate for the function being performed.
  • Any inappropriate access is addressed.
  • Management acknowledges that access remains appropriate.

 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

8.6.3

Passwords/passphrases for any application and system accounts are protected against misuse as follows:

  • Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.
  • Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.

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.

About PHIL DORCZUK

Phil Dorczuk is a Senior Associate with Schellman. Prior to joining Schellman, LLC in 2013, Phil worked as a PCI DSS auditor with Coalfire Systems and a consultant at GTRI. At Coalfire, Phil specialized in PCI DSS audits and gap assessments and at GTRI specialized in Cisco network equipment installation and configuration.