6.5: 1. Changes to all system components in the production environment are made according to established procedures that include: (a) Reason for, and description of, the change, (b) Documentation of security impact, (c) Documented change approval by authorized parties, (d) Testing to verify that the change does not adversely impact system security, (e) For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production, (f) Procedures to address failures and return to a secure state.
  • Examine documented change control procedures to verify procedures are defined for changes to all system components in the production environment to include all elements specified in this requirement.
  • Examine recent changes to system components and trace those changes back to related change control documentation. For each change examined, verify the change is implemented in accordance with all elements specified in this requirement.

Description

Purpose

Change management procedures must be applied to all changes—including the addition, removal, or modification of any system component—in the production environment. It is important to document the reason for a change and the change description so that relevant parties understand and agree the change is needed. Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes.

Good Practice

Approval by authorized parties confirms that the change is legitimate and that the change is sanctioned by the organization. Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change.

Thorough testing by the entity confirms that the security of the environment is not reduced by implementing a change and that all existing security controls either remain in place or are replaced with equal or stronger security controls after the change. The specific testing to be performed will vary according to the type of change and system component(s) affected.

For each change, it is important to have documented procedures that address any failures and provide instructions on how to return to a secure state in case the change fails or adversely affects the security of an application or system. These procedures will allow the application or system to be restored to its previous secure state.

6.5: 2. Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.
  • Examine documentation for significant changes, interview personnel, and observe the affected systems/networks to verify that the entity confirmed applicable PCI DSS requirements were in place on all new or changed systems and networks and that documentation was updated as applicable.

Description

Purpose

Having processes to analyze significant changes helps ensure that all appropriate PCI DSS controls are applied to any systems or networks added or changed within the in-scope environment, and that PCI DSS requirements continue to be met to secure the environment.

Good Practice

Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed.

Examples

Applicable PCI DSS requirements that could be impacted include, but are not limited to:

• Network and data-flow diagrams are updated to reflect changes.

• Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled.

• Systems are protected with required controls—for example, file integrity monitoring (FIM), anti- malware, patches, and audit logging.

• Sensitive authentication data is not stored, and all account data storage is documented and incorporated into data retention policy and procedures.

• New systems are included in the quarterly vulnerability scanning process.

• Systems are scanned for internal and external vulnerabilities after significant changes per Requirements 11.3.1.3 and 11.3.2.1.

6.5: 3. Pre-production environments are separated from production environments and the separation is enforced with access controls.
  • Examine policies and procedures to verify that processes are defined for separating the pre- production environment from the production environment via access controls that enforce the separation.
  • Examine network documentation and configurations of network security controls to verify that the pre-production environment is separate from the production environment(s).
  • Examine access control settings to verify that access controls are in place to enforce separation between the pre-production and production environment(s).

Description

Purpose

Due to the constantly changing state of pre- production environments, they are often less secure than the production environment.

Good Practice

Organizations must clearly understand which environments are test environments or development environments and how these environments interact on the level of networks and applications.

Definitions

Pre-production environments include development, testing, user acceptance testing (UAT), etc. Even where production infrastructure is used to facilitate testing or development, production environments still need to be separated (logically or physically) from pre-production functionality such that vulnerabilities introduced as a result of pre-production activities do not adversely affect production systems.

6.5: 4. Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
  • Examine policies and procedures to verify that processes are defined for separating roles and functions to provide accountability such that only reviewed and approved changes are deployed.
  • Observe processes and interview personnel to verify implemented controls separate roles and functions and provide accountability such that only reviewed and approved changes are deployed.

Description

Purpose

The goal of separating roles and functions between production and pre-production environments is to reduce the number of personnel with access to the production environment and account data and thereby minimize risk of unauthorized, unintentional, or inappropriate access to data and system components and help ensure that access is limited to those individuals with a business need for such access.

The intent of this control is to separate critical activities to provide oversight and review to catch errors and minimize the chances of fraud or theft (since two people would need to collude in order to hide an activity).

Separating roles and functions, also referred to as separation or segregation of duties, is a key internal control concept to protect an entity’s assets.

6.5: 5. Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements.
  • Examine policies and procedures to verify that processes are defined for not using live PANs in pre-production environments, except where those environments are in a CDE and protected in accordance with all applicable PCI DSS requirements.
  • Observe testing processes and interview personnel to verify procedures are in place to ensure live PANs are not used in pre-production environments, except where those environments are in a CDE and protected in accordance with all applicable PCI DSS requirements.
  • Examine pre-production test data to verify live PANs are not used in pre-production environments, except where those environments are in a CDE and protected in accordance with all applicable PCI DSS requirements.

Description

Purpose

Use of live PANs outside of protected CDEs provides malicious individuals with the opportunity to gain unauthorized access to cardholder data.

Definitions

Live PANs refer to valid PANs (not test PANs) issued by, or on behalf of, a payment brand. Additionally, when payment cards expire, the same PAN is often reused with a different expiry date. All PANs must be verified as being unable to conduct payment transactions or pose fraud risk to the payment system before they are excluded from PCI DSS scope. It is the responsibility of the entity to confirm that PANs are not live.

6.5: 6. Test data and test accounts are removed from system components before the system goes into production.
  • Examine policies and procedures to verify that processes are defined for removal of test data and test accounts from system components before the system goes into production.
  • Observe testing processes for both off-the- shelf software and in-house applications, and interview personnel to verify test data and test accounts are removed before a system goes into production.
  • Examine data and accounts for recently installed or updated off-the-shelf software and in- house applications to verify there is no test data or test accounts on systems in production.

Description

Purpose

This data may give away information about the functioning of an application or system and is an easy target for unauthorized individuals to exploit to gain access to systems. Possession of such information could facilitate compromise of the system and related account data.