Assessing PCI-DSS compliance for Red Hat OpenStack Platform
Considering relevant factors
To begin evaluating whether your OpenStack deployment is compliant with the PCI-DSS standards for user authentication and authorization, you will need to take the following factors into account (among others):
- The version of OpenStack.
- The version of PCI-DSS.
- How OpenStack was deployed and configured.
- Which Identity Service (keystone) back ends are in use.
- Which keystone authentication plug-ins are in use.
The objective of PCI-DSS can be considered an ongoing task, as the components required to meet certain PCI-DSS standards have been added to OpenStack over the course of multiple releases, and have continued to evolve since.
Considering each requirement
This document attempts to consolidate all the necessary elements required to help inform a PCI-DSS compliance review. The approach is to list each PCI-DSS requirement found in section 8 of the current PCI-DSS specification, and then explain how OpenStack addresses it by enumerating the following details for each one:
- The PCI-DSS requirement.
- Does OpenStack satisfy the requirement?
- How OpenStack satisfies the requirement?
- When was support for the requirement added to OpenStack?
- What was the Gerrit review that introduced the support requirement?
- Any expository material relevant to the requirement unique to OpenStack.
IMPORTANT: PCI-DSS compliance in OpenStack applies only to the keystone SQL identity back end. If any other identity back end is used, then it is the responsibility of that driver to implement the PCI-DSS compliance. This includes the use of federated identity services, even when federation is used in conjunction with shadow users.
NOTE: Certain OpenStack projects can operate outside of OpenStack, with their authentication systems also being independent of OpenStack. The OpenStack Object Store (swift) is such an example: Typically, when swift is used in an OpenStack environment it will be configured to use keystone authentication, however this is not mandatory. Consequently, you must be aware that the discussions concerning PCI-DSS apply only to those components using keystone authentication.
For more information on swift authentication, see https://docs.openstack.org/swift/latest/overview_auth.html.
OpenStack Multi-factor authentication
There are multiple PCI-DSS requirements refer to multi-factor authentication (MFA), so to avoid duplicating the discussion of MFA, the material on MFA is combined here under one section.
Multi-factor authentication (MFA) support was added to keystone in the Red Hat OpenStack Platform 11 (Ocata) release. The Per-User Auth Plugin Requirements blueprint describes how MFA is intended to work: https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/per-user-auth-plugin-requirements.html
The Keystone Ocata Release Notes describe how to configure and use the per-user MFA functionality. See the section titled blueprint per-user-auth-plugin-reqs.
The MFA rules must be explicitly set for every user, which is why it is not referred to as MFA. As of the Queens release there is no site-wide global MFA rules that applies to all users by default, so the initial MFA blueprint is on a per-user basis. If site-wide default MFA rules are added, then it is anticipated that the site-wide MFA rules will follow the same model as the per-user rules.
IMPORTANT: Keystone MFA satisfies the PCI-DSS MFA requirement, but because keystone MFA is managed on a per-user basis it adds an additional workflow burden. A failure to set MFA rules on a user (either previously provisioned or newly provisioned) invalidates PCI-DSS MFA requirements 8.3, 8.3.1, and 8.3.2.
NOTE: The only traditional 2nd factor auth method currently supported by keystone is Time-based One-time Password (TOTP). TOTP was added in Red Hat OpenStack Platform 9 (Mitaka) and is described here: https://docs.openstack.org/keystone/latest/advanced-topics/auth-totp.html
NOTE: PCI-DSS MFA 8.3 requirements specify MFA for non-console and remote network access. Keystone is unable to distinguish the origin of the authentication request therefore MFA must be enabled in all contexts.
PCI DSS Requirements
Below are the all the PCI-DSS requirements from section 8 of the PCI-DSS specification. In addition, details are supplied on the circumstances under which OpenStack satisfies the requirement.
Requirement 8.1
Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components.
- How OpenStack addresses this:
This is a site management task.
Conclusion: Not Applicable.
Requirement 8.1.1
Assign all users a unique ID before allowing them to access system components or cardholder data.
- How OpenStack addresses this:
The core SQL identity back end has always provisioned a unique user ID.
Conclusion: Satisfied
Requirement 8.1.2
Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
- How OpenStack addresses this:
The keystone v3 Users API https://developer.openstack.org/api-ref/identity/v3/#users provides:
- List Users
- Create User
- Show user details
- Update User
- Delete User
- List groups to which a user belongs
- List projects for user
- Change password for user
The keystone v3 Credentials API https://developer.openstack.org/api-ref/identity/v3/#credentials provides:
- Create credential
- List credentials
- Show credential details
- Update credential
- Delete credential
CONCLUSION: Satisfied
Requirement 8.1.3
Immediately revoke access for any terminated users.
- How OpenStack addresses this:
The keystone v3 Token API provides revoke-token https://developer.openstack.org/api-ref/identity/v3/#revoke-token which immediately revokes a token. However there are a few considerations to be aware of:
Validating the identity of every client on every request can impact performance for both the OpenStack service and the identity service. As a result, keystonemiddleware is configurable to cache authentication responses from the identity service. Tokens that become invalidated may continue to work after they have been stored in the cache. See this configuration option:
# default 300 seconds
# Set to -1 to disable caching completely.
token_cache_time = 300
NOTE: Service accounts may allow a token to continue to be used past its expiration. However this PCI-DSS requirement addresses the revocation of users and not service accounts, therefore this does not apply.
Conclusion: Satisfied (with appropriate configuration)
Requirement 8.1.4
Remove/disable inactive user accounts within 90 days.
- How OpenStack addresses this:
See Disabling inactive users for more information: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#disabling-inactive-users
Relevant OpenStack Change: https://review.openstack.org/#/c/328447/
First Appeared in Release: Red Hat OpenStack Platform 10 (Newton)
Conclusion: Satisfied
Requirement 8.1.5
Manage IDs used by third parties to access, support, or maintain system components via remote access as follows:
* Enabled only during the time period needed and disabled when not in use.
* Monitored when in use.
- How OpenStack addresses this:
OpenStack provides multiple ways to disable a user:
- Set the user
enabledflag tofalse. - Remove all roles from the user.
- Remove all projects from the user.
The user enabled flag enables or disables the user. An enabled user can authenticate and receive authorization. A disabled user cannot authenticate or receive authorization. In addition, all tokens that the user holds become no longer valid. If you re-enable this user, pre-existing tokens do not become valid. To enable the user, set to true. To disable the user, set to false. The default is true.
User activity can be monitored through the Audit Middleware OpenStack component. For more information, see https://docs.openstack.org/keystonemiddleware/latest/audit.html.
Conclusion: Satisfied
Requirement 8.1.6
Limit repeated access attempts by locking out the user ID after not more than six attempts.
- How OpenStack addresses this:
See the Setting an account lockout threshold section for more information: https://docs.openstack.org/keystone/latest/admin/configuration.html#security-compliance-and-pci-dss
OpenStack Change: https://review.openstack.org/#/c/340074/
First Appeared in Release: Red Hat OpenStack Platform 10 (Newton)
Conclusion: Satisfied
Requirement 8.1.7
Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
- How OpenStack addresses this:
See the lockout_duration section in Setting an account lockout threshold for more information: https://docs.openstack.org/keystone/latest/admin/configuration.html#security-compliance-and-pci-dss
OpenStack Change: https://review.openstack.org/#/c/340074/
First Appeared in Release: Red Hat OpenStack Platform 10 (Newton)
Conclusion: Satisfied
Requirement 8.1.8
If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.
- How OpenStack addresses this:
Keystone has a token.expiration configuration value. From the keystone token documentation:
# The amount of time that a token should remain valid (in seconds). Drastically
# reducing this value may break "long-running" operations that involve multiple
# services to coordinate together, and will force users to authenticate with
# keystone more frequently. Drastically increasing this value will increase
# load on the `[token] driver`, as more tokens will be simultaneously valid.
# Keystone tokens are also bearer tokens, so a shorter duration will also
# reduce the potential security impact of a compromised token. (integer value)
# Minimum value: 0
# Maximum value: 9223372036854775807
#expiration = 3600
OpenStack Change: https://review.openstack.org/#/c/3942/
First Appeared in Release: essex-4
Conclusion: Satisfied
Requirement 8.2
In addition to assigning a unique ID, ensure proper
user-authentication management for non-consumer users and
administrators on all system components by employing at least one of
the following methods to authenticate all users:
* Something you know, such as a password or passphrase.
* Something you have, such as a token device or smart card.
* Something you are, such as a biometric.
- How OpenStack addresses this:
OpenStack requires both authentication and authorization for virutally all operations.
Conclusion: Satisfied
Requirement 8.2.1
Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.
- How OpenStack addresses this:
Requirement 8.2.1 is actually two independent requirements:
- encrypt credentials in transit
- encrypt credentials at rest
The first requirement to encrypt credentials in-transit is satisfied when Keystone requires the TLS protocol for client connection. The use of TLS is not a function of OpenStack as such, instead, TLS and its configuration properties fall within the OpenStack deployment tools. As of this writing most of the deployment tools support TLS, however, it is important to note even if a client is required to use TLS to connect to keystone it may not be an end-to-end TLS connection if keystone is deployed in a high availability (HA) environment. This is because in most HA deployments TLS is terminated at the front end public endpoint, which then forwards the unencrypted communication on a private internal network to one of many back end servers through a load-balancing arrangement. As a result, the public communication is encrypted but unencrypted data is exposed on the private internal network. If the private internal network is considered vulnerable then most load balancers can be configured to use TLS on the private network. All of this is managed by the deployment and not OpenStack.
The second requirement to encrypt credentials at-rest was implemented in Red Hat OpenStack Platform 10 (Newton), see the Credential Encryption documentation for details. As noted above for the first requirement, enabling this feature requires configuration outside the scope of OpenStack proper; most OpenStack deployment tools now support management of the encryption keys required to support credential encryption.
OpenStack Change: https://review.openstack.org/#/c/355618/
First Appeared in Release: Red Hat OpenStack Platform 10 (Newton)
Conclusion: Satisfied (with appropriate configuration)
Requirement 8.2.2
Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys.
- How OpenStack addresses this:
This is a site management task. OpenStack provides the necessary tools but it is up to the site to implement the necessary workflow.
Conclusion: Not Applicable.
Requirement 8.2.3
Passwords/passphrases must meet the following:
* Require a minimum length of at least seven characters.
* Contain both numeric and alphabetic characters.
- How OpenStack addresses this:
See the Password Strength documentation for details: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#configuring-password-strength-requirements
OpenStack Change: https://review.openstack.org/#/c/320586/
First Appeared in Release: Red Hat OpenStack Platform 10 (Newton)
Conclusion: Satisfied
Requirement 8.2.4
Change user passwords/passphrases at least once every 90 days.
- How OpenStack addresses this:
See the Password Expiration documentation for details: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#configuring-password-expiration
OpenStack Change: https://review.openstack.org/#/c/333360/
First Appeared in Release: Red Hat OpenStack Platform 10 (Newton)
Conclusion: Satisfied
Requirement 8.2.5
Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used.
- How OpenStack addresses this:
See the Password History documentation for details: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#requiring-a-unique-password-history
OpenStack Change: https://review.openstack.org/#/c/328339/
First Appeared in Release: Red Hat OpenStack Platform 10 (Newton)
Conclusion: Satisfied
Requirement 8.2.6
Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.
- How OpenStack addresses this:
See the Password First Use documentation for details: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#force-users-to-change-password-upon-first-use
OpenStack Change: https://review.openstack.org/#/c/425507/
First Appeared in Release: Red Hat OpenStack Platform 11 (Ocata)
Conclusion: Satisfied
Requirement 8.3
Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.
- How OpenStack addresses this:
See the OpenStack Multi-factor authentication section for details and make note of how the console compares to non-console in that section.
Conclusion: Satisfied
Requirement 8.3.1
Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
- How OpenStack addresses this:
See the OpenStack Multi-factor authentication section for details and make note of how the console compares to non-console in that section.
Conclusion: Satisfied
Requirement 8.3.2
Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.
- How OpenStack addresses this:
See the OpenStack Multi-factor authentication section for details.
Conclusion: Satisfied
Requirement 8.4
Document and communicate authentication policies and procedures to all users including:
* Guidance on selecting strong authentication credentials.
* Guidance for how users should protect their authentication credentials.
* Instructions not to reuse previously used passwords.
* Instructions to change passwords if there is any suspicion the password could be compromised.
- How OpenStack addresses this:
This is a site management task.
Conclusion: Not Applicable.
Requirement 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.
- How OpenStack addresses this:
This is a site management task.
Conclusion: Not Applicable.
Requirement 8.5.1
Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
- How OpenStack addresses this:
This is a site management task. OpenStack provides the necessary tools but it is up to the site to implement the necessary workflow.
Conclusion: Not Applicable.
Requirement 8.6
Where other authentication mechanisms are used (for example,
physical or logical security tokens, smart cards, certificates, etc.),
use of these mechanisms must be assigned as follows:
* Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
* Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
- How OpenStack addresses this:
This is a site management task.
Conclusion: Not Applicable.
Requirement 8.7
All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
* All user access to, user queries of, and user actions on databases are through programmatic methods.
* Only database administrators have the ability to directly access or query databases.
* Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
- How OpenStack addresses this:
This is a deployment issue. OpenStack itself does not enforce restrictions on database access. However, the tools that deploy OpenStack usually enforce this, but given the number of deployment scenarios and tools this can only be verified by auditing the deployment to assure the database is locked down and any credentials needed to access it are secured.
Conclusion: Outside of scope for OpenStack and keystone.
Requirement 8.8
Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
- How OpenStack addresses this:
This is a site management task.
Conclusion: Not Applicable.
Further information
-
OpenStack PCI-DSS Security Compliance: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html
-
OpenStack Newton PCI-DSS Specification: https://specs.openstack.org/openstack/keystone-specs/specs/keystone/newton/pci-dss.html
Comments