Does PCI-DSS password guidance apply to service accounts?

Question

A service account is a user account created for the sole purpose of running an application. For example, an online banking web site may have a single service account under which the code runs.

Service accounts, like any other accounts, have passwords. They differ from end user accounts' passwords in two important ways:

1. The passwords are generated by us (and they are big and random)
2. The passwords are stored by Windows so that it can start the services when needed without human interaction.

I am trying to figure out what sort of password management process we need to stand up around these accounts.

PCI-DSS guidance sets the following general guidance for passwords:

• Assign all users a unique ID before allowing them to access system components or cardholder data.
• Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
• Immediately revoke access for any terminated users.
• Remove/disable inactive user accounts within 90 days.
• Limit repeated access attempts by locking out the user ID after not more than six attempts.
• Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
• If a session has been idle for more than 15 minutes, require the user to reauthenticate to re-activate the terminal or session.
• Change user passwords/passphrases at least once every 90 days

But some of these rules do not make any sense for a service account. For example, maybe it doesn't make sense to enforce lockout. And it could be a real pain in the neck to change the password every 90 days, if the same identity is used for a series of microservices, for example.

Do any of these rules apply to service accounts, or only to end user accounts? If the rules are just for end user accounts, what rules exist (if any) for service accounts?

(By "apply" I mean "are considered during a PCI audit")

Answer 1

Your use of the word 'guidance' is a but off.

Under the standard there are 4 parts per requirement:

• The requirement itself
• Testing procedures
• Reporting instructions

• Guidance

  These can be found under the ROC and Standard documents in the PCI SSC Document Library.

Requirement 8.2.4 states:

Change user passwords/passphrases at least once every 90 days.

It has its matching Testing Procedure:

For each item in the sample, describe how system configuration settings verified that user password/passphrase parameters are set to require users to change passwords/passphrases at least once every 90 days.

Its guidance however provides the intent behind the requirement:

Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.

So IF you can show you can pass the intent (guidance) without changing your password every 90 days without using another requirement (by compensating control worksheet) by say, having a password with such complexity that its hash can not be cracked within its used time, with additional logging (above the requirements) etc. Then the QSA might say the requirement has met the intent.

Some definitions of what counts as an 'Admin' account for your service accounts (however 'the standard' overwrites all FAQs and 'Guidance' documentation at will of PCI and the QSA).

Answer 2

The real answer is whatever a QSA says when you're audited.

If you have official channels to ask, use them. Get an answer in writing, if possible.

Automated compliance is the best route; as manual action increases, so does the likelihood of human error.

At a former employer, we were very risk-averse on questions of compliance. In this case, we handled service accounts like any other user account.

Automation is more or less necessary if you have anything beyond a tiny footprint. We considered several approaches to fulfilling these requirements.

Our Three Options

On Windows, if you use group managed service accounts (GMSAs), they are technically machine accounts rather than user accounts, plus password changes are handled automatically. No cost if you have a Windows domain, but it must be at the 2012 level or higher.

You can use an application such as Secret Server, which will change, store, validate, etc the passwords for you. Unlike GMSAs, your admins can authenticate manually if they need to do testing or troubleshooting---potentially a plus, depending on your environment. However, there is a licensing fee to consider, plus it's another application/database to manage.

Change the password and update the service configs via script. You can use PowerShell to change the account password and then push that change to your devices with the Set-Service commandlet. This costs no money upfront, but it is more labor-intensive than GMSAs since you'll have to write and maintain the script(s).