Last updated at Tue, 29 Aug 2017 23:59:16 GMT
What's a Privileged account?
The term "Privileged account", also known as "High Privileged account" or "Super user" refers to any type of account that holds special or extra permissions within the enterprise systems.
They are generally categorized as:
- IT administrative accounts used to install or configure. E.g.UNIX root, Windows Administrator accounts or accounts associated with database ownership and network components.
- Identity and access management accounts used to manage users and roles.
- Application accounts: The application accounts used to access databases or other applications/systems
- Emergency Accounts: Special accounts used when elevated privileges are required to fix urgent matters.
The Key to the kingdom problem
According to Verizon, many organizations do not have any solution to control usage of privileged accounts . Usage of shared/generic privileged accounts is a common bad practice at the top of auditor findings
Privileged accounts provide a kind of unlimited power to the ones who are in their possession. Beside the accidental and disastrous damages resulting from erroneous usages of highly risky commands, such privileges open the way to malicious activities under the radar. Equipped with their super power, administrators can conceal their actions in various ways such as stopping/modifying or deleting the logs, hide behind a shared accounts or put on Harry Potter's invisibility cloak through a sudo root command.
History is full of examples of individuals having diverted their privileges for their own profits. After all, aren't we all subjected to temptation? In that case, who in your opinion is the more guilty: the ones having misused their privileges or the ones having assigned them with unlimited and uncontrolled privileges?
Additionally, as reported by Verizon, shared privileged accounts are unfortunately a quite common finding. In this case, password changes become a nightmare as it needs some sort of coordination. Additionally, any account lockout (due to wrong password entries) can be catastrophic. Consequently, in these shared environment passwords are generally not changed and the associated accounts never lockout.
So it's not a good practice to give the key to the kingdom to someone or worse a copy of the key to a group of persons even if they look quite innocent. On the name of the « We never know », the principle of precaution should be applicable here.
For these reasons, it should not be surprising that the usage, management, and monitoring of these accounts are at the the top of the auditor's findings list and are an essential component of PCI DSS compliance.
Associated PCI requirements
The following requirements are associated to the control of privileges accounts:
- 7.1: Limit access to system components and cardholder data to only those individuals whose job requires such access.
- 7.1.1: Restriction of access rights to privileged user Id's to least privileges necessary to perform their job
- 7.1.2: Assignment of privileges is based on individual personnel's job classification and function.
- 8.5: Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
- Generic user IDs are disabled or removed.
- Shared user IDs do not exist for system administration and other critical functions.
- Shared and generic user IDs are not used to administer any system components.
- 10.2.2: Implement automated audit trails for all system components to reconstruct All actions taken by any individual with root or administrative privileges
- 10.2.3: Implement automated audit trails for all system components to reconstruct Access to all audit trails
- 10.2.6: Implement automated audit trails for all system components to reconstruct Initialization of the audit logs10.5Secure audit trails so they cannot be altered.
- 10.5.1: Limit viewing of audit trails to those with a job-related need.
- 10.5.2: Protect audit trail files from unauthorized modifications.
What to do and how to comply?
Complying with the above PCI requirements is a brainteaser without considering implementation of a PAM (Privileged Accounts Management) solution. They generally consist of the following parts:
- Control of access through a password vault/gateway. IT staff are personally authenticated prior to requesting, approving, or gaining access to a privileged account. This ensures accountability for changes they may make using that account.
- Periodic randomization of the passwords associated with privileged accounts. This means that they cannot be shared or stored in plaintext files.
- Restriction of commands/actions to the minimum necessary. Privileged commands are limited and invisible administrators prevented.
- Real time capture and forward of executed commands/actions to a central place for logging and monitoring purpose. At the minimum: who connected to which account on which system at what time from what device, which commands have been executed, and in some cases, key logging and even full screen captures of the whole sessions.
For big merchants/organizations implementation of an enterprise-level PAM solution is probably the only way to constraint their key to the Kingdom problem. Unfortunately most of these solutions are probably not affordable for small/medium organizations, leaving them in a certain "no-compliance" land. Some of them tempt their to approach compliance through the use of group/team password managers (which does not answer the whole spectrum of the problem) and many organizations do not have any privileged account or password management solution at all.
Small companies could potentially decide to implement a strict dual control on all administrative activities that would be acceptable for PCI compliance. However such solution is probably not applicable in a time where we see more and more individuals assigned to multi-tasking than a task assigned to two individuals.
PAM Products
Such product class has experienced explosive growth in the past years. There are several leading privileged account management solutions available that have mature enterprise functionality including: CyberArk -Enterprise Password Vault, BeyondTrust-PowerBroker, Hitachi ID Privilged Access Manager, Avecto - Privege Guard, Centrify-DirectAuthorize and Directaudit, Dell One Identity solutions, CA-ControlMinder.
Questions
- Organization/QSA/ISA - How do you see this topic addressed?
- Any recommendation?
- Any other solution to recommend?
Have you read our previous newsletter: PCI 30 seconds newsletter #35 - Patch management, how to comply with PCI.
Other resources:
PCI Newsletters published so far
Didier Godart
