Like individual user accounts, system and application accounts require accountability and strict management to ensure they are used only for the intended purpose and are not misused.
Attackers often compromise system or application accounts to gain access to cardholder data.
Where possible, configure system and application accounts to disallow interactive login to prevent unauthorized individuals from logging in and using the account with its associated system privileges, and to limit the machines and devices on which the account can be used.
Interactive login is the ability for a person to log into a system or application account in the same manner as a normal user account. Using system and application accounts this way means there is no accountability and traceability of actions taken by the user.
Refer to Appendix G for the definition of “application and system accounts.”
Not properly protecting passwords/passphrases used by application and system accounts, especially if those accounts can be used for interactive login, increases the risk and success of unauthorized use of those privileged accounts.
Changing these values due to suspected or confirmed disclosure can be particularly difficult to implement.
Tools can facilitate both management and security of authentication factors for application and system accounts. For example, consider password vaults or other system-managed controls.
Systems and application accounts pose more inherent security risk than user accounts because they often run in an elevated security context, with access to systems that may not be typically granted to user accounts, such as programmatic access to databases, etc. As a result, special consideration must be made to protect passwords/passphrases used for application and system accounts.
Entities should consider the following risk factors when determining how to protect application and system passwords/passphrases against misuse:
• How securely the passwords/passphrases are stored (for example, whether they are stored in a password vault).
• Staff turnover.
• The number of people with access to the authentication factor.
• Whether the account can be used for interactive login.
• Whether the security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly (see Requirement 8.3.9).
All these elements affect the level of risk for application and system accounts and might impact the security of systems accessed by the system and application accounts.Entities should correlate their selected change frequency for application and system passwords/passwords with their selected complexity for those passwords/passphrases – i.e., the complexity should be more rigorous when passwords/passphrases are changed infrequently and can be less rigorous when changed more frequently. For example, a longer change frequency is more justifiable when passwords/passphrases complexity is set to 36 alphanumeric characters with upper- and lower- case letters, numbers, and special characters.
Best practices are to consider password changes at least once a year, a password/passphrase length of at least 15 characters, and complexity for the passwords/passphrase of alphanumeric characters, with upper- and lower-case letters, and special characters.
For information about variability and equivalency of password strength for passwords/passphrases of different formats, see the industry standards (for example, the current version of NIST SP 800- 63 Digital Identity Guidelines ).