Document Comparison

PCI_Card_Production_Logical_Security_Requirements_v2.pdf PCI%20CP_Logical_SR_TPs_v3.pdf
56% similar
66 → 115 Pages
19031 → 41552 Words
376 Content Changes

From Revision History

  • December 2012 1.x RFC version

Content Changes

376 content changes. 129 administrative changes (dates, page numbers) hidden.

Added p. 6
• Perform cloud-based or secure element (SE) provisioning services;

• Manage associated cryptographic keys.
Added p. 7
Loss Prevention Compliance with the requirements specified in this manual will not warrant or imply the prevention of any or all unexplained product losses. Approved vendors are responsible for preventing any such losses. Vendors are liable for any unexplained loss, theft, deterioration, or destruction of card products or components that may occur while such products are in the vendor’s facility. Vendors are required to carry liability insurance covering all the risks stated above, taking into consideration the plant location, physical conditions and security of the plant, the number and duties of the employees, and the nature and volume of the contracted work.

Limitations Transaction authorization and settlement activities are performed on networks and systems that are separate from the card production and provisioning environment and are out of scope for this document.

Section 1: Roles and Responsibilities 1.1 Information Security Personnel Requirement Test Procedure

Examine applicable policies and procedures to verify that a …
Added p. 9
Interview the CISO and examine documentation to conclude the individual or an appropriate designee has responsibility the vendor security environment.

vi. The back-up CISO and the IT Security Manager must be employees of the vendor.

Interview the back-up CISO to verify role.

Examine employment documentation to verify employment and position.

Examine logs or similar documentation to confirm the backup CISO does not perform activities related to the approval process for the vendor’s Information Security Management and security of the cloud- based provisioning platform for which they have approval responsibility.

Examine documentation to authenticate the manager’s security roles and responsibilities are clearly defined.

Interview security personnel or examine documentation

•e.g., reviewing accounts on personalization machines and in the production workflow

•to determine independence exists between day-to-day production operations and personnel performing security compliance assessments for those same production activities.

Section 2: Security Policy and Procedures 2.1 Information Security Policy Requirement Test Procedure

Examine the information security policy and verify that the …
Added p. 11
Examine procedural documents to ensure procedures have been defined for each function described in the ISP•e.g., password policy, remote access policy.

Interview a sample of staff to determine that procedures are followed to support compliance with these Security Requirements.

Examine evidence that the procedures are reviewed, validated, and where necessary, updated annually.

Examine policies to verify that they clearly define information security responsibilities for all personnel.

Interview a sample of responsible personnel to verify they understand the security policies.

Examine the incident response plan and related procedures to verify the entity has a documented IRP addressing known or suspected compromise of any classified data.

Interview personnel to determine that the IRP is communicated to relevant parties.

Interview staff to determine that they report any unexpected or unusual activity relating to production equipment and operations.

Examine evidence of existence of reported incidents.
Added p. 12
Examine reported incidences to verify that law enforcement agencies were included in the written notification. Each notification must include at minimum the information outlined in Requirement 3.3c.

Examine written notifications to determine weekly updates were issued during the investigation process.

Examine reports to determine a final report was provided and that the report contains results and any remediation.

Examine incident response procedures to identify what logs, documents, equipment, or other relevant information is being preserved. Validate identified information is being preserved.

• Chip personalization keys

• PIN keys and keys used to generate CVVs, CVCs, CAVs, or CSCs

• PINs Confidential Data Confidential data is considered as any information that might provide the vendor with a competitive advantage or could cause business harm or legal exposure if the information is used or disclosed without restriction. Confidential data is data restricted to authorized individuals. This includes cardholder data and the keys used to encrypt cardholder data.

• PAN, …
Added p. 15
Examine documentation that describes the data flow to verify secret and confidential cardholder data:

• Is decrypted only on the data-preparation, personalization, or cloud-based provisioning systems.

• Is never decrypted while the data is on an Internet- or public-facing network.

• Remains encrypted in the DMZ. Additional validation and assurance can be provided through checking the DMZ network for decryption/encryption software.

Examine documentation to verify that the cardholder data access policy and procedure are documented.

Observe a demonstration showing authorized access to cardholder data and that access attempted by an unauthorized user is declined.

Examine access-control settings to verify cardholder data cannot be accessed from outside the cloud- based provisioning and personalization networks and systems.

Examine access-control settings to verify logical access to the data preparation and personalization networks is prevented from outside the high security area (HSA).

Examine a sample of access-control settings to verify that:

• The access rights for the individual are known.

• The reason for …
Added p. 16
Examine a sample of audit trails to verify they exist for individual access to cardholder data and provide sufficient detail to identify the individual user.

Examine evidence that PANS are masked such that only the first six and last four digits are visible when displayed or printed.

Examine evidence to verify that when a PAN is not masked the issuer has authorized the visible PAN and that the business justification is documented.

For all third-party service providers that have access to cardholder or provisioning data:

• Examine evidence that a formal contract with the service provider exists and that it includes identification of and compliance with the applicable security policies and standards.

• Examine evidence to verify that access to cardholder and cloud-based provisioning data is not provided until a formal contract defining access terms is signed.

Examine database-access policies and procedures to verify that only authorized database administrators are granted direct access to cardholder or …
Added p. 18
Examine policies and procedures to verify that a data-retention policy exists.

Examine evidence that the retention policy is followed.

Examine a sample of retained cardholder data to verify that it is not retained longer than 30 days after personalization unless the issuer has authorized longer retention in writing. Verification of data deletion must include any data backups and return files in the DMZ that contain cardholder data.

Examine evidence of issuer authorization for personalization data retained longer than 30 days after personalization.

Examine issuer authorization that allows for cardholder data retention longer than 30 days to verify that the authorization is less than two years old.

Examine a sample of cardholder data authorized for retention longer than 30 days and verify that:

• Cardholder data is deleted in compliance with the authorized retention period.

• Cardholder data is not retained longer than the six-month maximum.

Examine a sample of completed batches to verify that cardholder data is deleted …
Added p. 19
Examine the vendor’s policies and procedures for removable media documentation to verify it exists and includes devices such as laptops, mobile devices, USB devices, tapes, and disks.

Observe a sample of removable media within the HSA to verify it is clearly labeled with a unique identifier and data classification.

Observe the removable media storage location to verify the area is secure.

Examine the removable media check-in/out process to verify an audit trail is maintained and that it provides an accurate record of media possession.

Examine a sample of checked-out, removable media within the HSA or the cloud-based provisioning environment to verify:

• The media is in the custody of the person to whom the media was issued.

• The individual is authorized to possess the media.

• That individual does not have the ability to decrypt any sensitive or confidential data contained on that media other than in compliance with procedures for handling sensitive or confidential data.

• …
Added p. 20
iv. Name and signature of custodian recipient

v. Reason for transfer Examine the media audit trail documentation to verify that it contains at least the following data points:

• Unique media identifier

• Date and time logged out and returned

• Name and signature of custodian recipient

Examine evidence that any transfer of checked out media is authorized and logged.

Examine a sample of media that was removed from the HSA to verify that the removal was authorized and logged.

Examine evidence that media containing secret or confidential media is destroyed in a manner that makes it impossible to recover the data.
Added p. 21
Examine evidence to verify that testing for personalization signals outside the HSA was performed after the last significant change to the personalization environment. Significant changes include but are not limited to:

• The introduction of new personalization equipment

• Modification of personalization equipment shielding

• Structural changes to the HSA perimeter

Examine evidence that encrypted personalization signals comply with the encryption requirements defined in Normative Annex A.

Examine evidence that manual or automated scans for rogue RF devices are performed at least twice per month.

Examine evidence to verify personalized contactless cards are stored and handled:

• As batches of two or more cards, or

• Enclosed within protective packaging that restricts reading card emissions 3.8 Data Used for Testing Requirement Test Procedure

Examine documented policies and procedures to verity test keys and test data are restricted from use in production.

Observe the location of the test environment to verify that it is separate from production.

Interview personnel to verify testing …
Added p. 22
Examine a sample of electronic logs to verify that successful and unsuccessful provisioning activity is logged.

Examine evidence that provisioning activity logs are retained for at least 45 days.

Examine policies and procedures to verify that there is a decommissioning plan by which assets associated with card production and provisioning activities are secured in the event production activities are discontinued.

Examine the decommissioning plan to verify it includes the process by which the following items, at a minimum, are secured:

• Card design materials

• Production hardware

Examine the decommissioning plan to verify that the disposition expectation is defined for each item covered in the plan.
Added p. 23
See Appendix B, “Topology Examples,” for network examples.

Data Preparation Network This is the network that contains the server(s) where the cardholder data is stored pending personalization. This is also the network where the data is prepared and sent to the production floor.
Added p. 23
Examine network diagrams and system configurations to verify that a DMZ dedicated to card production/provisioning activities is established.

Examine network diagrams and system configurations to verify that card production and provisioning network(s) are segregated from other parts of an organization's network.

Examine network diagram to verify all communication to and from the personalization network is exchanged via a system in the DMZ.

Observe the DMZ system components to verify they are located in dedicated rack(s) capable of restricting individual access.

Examine policies and procedures regarding access to the dedicated rack(s) and verify the list of individuals with access is restricted to the minimum number of individuals required for effective operations.

Observe DMZ switches and cabling to verify they are all stored within the same rack.

Observe the DMZ cable connections to verify that only the minimum number of cable connections required to provide connectivity to firewalls are entering/exiting the rack.
Added p. 24
Examine network diagrams to verify that the HCE provisioning system is separated from other personalization network systems.

Examine logical configuration settings

•e.g., firewall rules

•to verify segmentation.

Examine network topology diagram to verify it exists, clearly defines the boundaries for all networks, and includes all system components that reside in the HSA.

Interview network administration personnel to verify the policy and procedures require topology review and update upon making changes to the network and at least annually.

Examine evidence that the network topology diagram was reviewed and updated when the network configuration was changed and at least within the last 12 months if there were no changes.

Examine evidence that the CISO has accepted the security implications of the current network topology and that the document includes his or her formal signature.
Added p. 25
Examine the cardholder and cloud-based provisioning data-flow diagram to verify that cardholder data flows across systems and networks from its receipt/generation to end of its lifecycle.

Interview the IT Manager to verify the diagram(s) are kept current and updated as needed and that it undergoes an overall review for accuracy at least every 12 months. .

•and Internet-connected networks. A virtual LAN (VLAN) is not considered a separate network.

Examine network configurations to verify personalization and data-preparation systems are on dedicated network(s) independent of the back office•e.g., through the use of a firewall(s) and not a VLAN between the personalization/data-preparation systems and the back office and Internet- connected networks.

Examine network diagrams and other relevant materials to verify that any cloud-based provisioning network is physically and logically segmented from the broader environment.

Observe where the cloud-based provisioning network components are housed to verify they are separate from other vendor networks and Internet-connected networks. For example, …
Added p. 26
Examine documented procedures to verify a process is in place to authorize all changes to network devices and protocols prior to implementation.

Examine a sample of change-management logs for network devices and protocols to verify the changes are authorized.
Added p. 27
Examine a sample of network device documentation to verify configuration settings, rulesets, and their justifications are documented.

Interview personnel to verify they are familiar with the documentation and process by which the documentation is updated.

Interview personnel to identify available services.

Examine evidence that available services were approved by an authorized security manager.

Examine documentation of logical and physical security controls that protect the integrity of network devices used to verify existence.

Observe a sample of the controls to verify effective implementation.

Interview personnel to verify mechanisms are defined and implemented to effectively monitor the activity on network devices.

Examine policies and procedures to verify mechanisms are defined to effectively monitor the activity on network devices.

Examine change-control documentation to verify there is a process for backing up network devices prior to any changes to those devices.

Examine procedures for backups and managing backup media to verify media are securely stored and managed.

Observe the media storage location to verify …
Added p. 28
Observe the firewall configuration documentation storage area to verify:

• Hard copy and non-digital documentation are stored in locked/secured areas accessible only to authorized personnel.

• Digital records are stored in a secure directory with access limited to authorized personnel.

b) Deploy an external firewall outside the HSA to protect the HSA’s DMZ (see figures 5-2 and 5-3 above for acceptable configurations).

Examine network diagrams and other relevant materials to verify that an external firewall outside the HSA is implemented to protect the HSA’s DMZ in accordance with acceptable configurations.

Examine firewall rules to verify that an external firewall is in place outside the HSA to protect the HSA’s DMZ.

Examine firewall rules to verify the separation via a firewall between the data-preparation network and the personalization network unless both are located within the same high security area or network.

Examine network diagrams and firewall rules to verify that firewalls are installed between the external network and …
Added p. 29
f) Implement appropriate operating-system controls on firewalls. Examine configurations to verify that appropriate operating-system controls are implemented on firewalls.

Examine evidence that firewall rule sets have been validated either:

• After every firewall configuration change and every 3 months.

Examine a sample of firewall rule sets to verify that their business justification is documented.

Observe the firewall/router environment to verify that that physical access to firewalls is limited to only those designated personnel who are authorized to perform administration activities.

Examine a sample of access rules to verify logical access is restricted to only those designated personnel who are authorized to perform firewall or router administration activities.

Examine firewall rules to verify that firewall and router configurations prohibit making outbound connection when only inbound traffic is expected.

Examine firewall rules to verify that firewall and router configurations prohibit incoming connections when only outbound traffic is expected.

Examine policies and procedures to verify that only authorized individuals can perform …
Added p. 31
e) If managed remotely, be managed according to Section 4.6, “Remote Access.” If firewalls are managed remotely, examine policy and procedures documentation to verify management activities are managed according to Section 4.6.

Interview personnel to identify necessary services, protocols, and ports.

Examine a sample of systems/networks to verify that unnecessary services are disabled.

Examine a sample of services, protocols, and ports to verify that their business justification is documented, and that they were approved by the IT Security Manager.

Examine policy and procedures to verify that administrator(s) are to be notified in real time of any items requiring immediate attention.

Interview administrators to verify that administrator(s) are notified in real time and that immediate attention is given when required.

• Center for Internet Security (CIS)

• International Organization for Standardization (ISO)

• SysAdmin Audit Network Security (SANS) Institute

• National Institute of Standards Technology (NIST) At a minimum, baseline configuration must address:

• User and group access security

• User and …
Added p. 32
Examine evidence to verify that the baseline security configuration was validated either:

Examine a sample of baseline configuration checks to verify that they occurred either:
Added p. 32
• Identification of security alerts

•e.g., subscribing to security alerts such as Microsoft and the Computer Emergency Response Team (CERT)

• Identification of security alerts

•e.g., subscribing to security alerts such as Microsoft and the Computer Emergency Response Team (CERT)

• Identification of system component updates that affect the supportability and stability of operating systems, software drivers, and firmware components

• Identification of system component updates that affect the supportability and stability of operating systems, software drivers, and firmware components

• Inventory of current systems in the environment including information about installed software components and about running services Examine policies and procedures documentation to verify coverage of:

• Inventory of current systems in the environment including information about installed software components and about running services Interview personnel to ensure procedures are known and followed.

Examine a sample of system components potentially affected by malicious software to verify that anti- virus software is deployed.

Examine a sample of system components …
Added p. 33
Examine policies and procedures to verify that anti-virus software and definitions are required to be kept up to date.

Examine a sample of systems to verify that either updates (based upon alerts collected as part of 4.5.a) were applied or documentation exists for why they were not.

Examine policies and procedures to verify that remote access is permitted only for the administration of the network or system components.

Examine a sample of users with remote access to verify such access is permitted only for the administration of the network or system components.

Examine a sample of system configurations to verify that remote access is not permitted from outside the facility to the physical access-control system except as used in connection an approved SOC.

Examine a sample of remote access system configurations and access logs to verify access is accepted only from pre-determined and authorized locations using vendor-approved systems.

Examine a sample of remote access system configurations …
Added p. 35
Interview a sample of non-vendor staff performing remote administration and verify that they maintain liability insurance to cover potential losses.

Examine policies and procedures to verify that personnel performing remote administration must meet the same pre-screening qualification requirements as employees working in high security areas.

Examine a sample of remote access to verify that remote access occurs using a VPN that meets the requirements of Section 4.6.2, “Virtual Private Network (VPN).” 4.6.2 Virtual Private Network (VPN)

Examine VPN system documentation and a sample of configuration settings to verify that:

• For remote access, VPNs must start from the originating device and terminate at either the target device or the personalization firewall.

• When terminating at the personalization firewall, an IPSec or TLS connection to the target device is used in accordance with PCI Data Security Requirement 4.1.

Examine policy and procedure documentation to verify that it defines that VPN tunnels for remote access to DMZ components …
Added p. 37
Examine usage policies to verify that they address wireless communications.

Interview a sample of personnel and validate that the policy is clearly communicated to all card production staff.

Examine wireless communications policies to verify that wireless communications are prohibited for the transfer of any personalization data and/or cloud-based provisioning data.

Examine a sample of connections to verify that connections are identified, analyzed, and documented including purpose, risk assessment, and action to be taken.

Examine output from recent wireless scans to verify that, at a minimum:

• The scan is performed for all wireless networks.

• Hidden and spoofed networks can be detected.

Examine output from recent wireless scans to verify that the WIDS is used to conduct random scans within the HSA at least monthly to detect rogue and hidden wireless networks.

Examine policies and procedures for resolving any issues identified when unauthorized connections or possible intrusions are detected to verify existence, including that investigations must occur immediately …
Added p. 39
Observe via a network-detecting device to determine whether SSIDs are being broadcast for any wireless communication channels used to transport any non-personalization data within or near the personalization environment•if yes, then a finding.

Examine policies and procedures to verify they require that all default security settings for wireless connections are changed upon installation including passwords, SSID, admin passwords, and Simple Network Management Protocol (SNMP) community strings.

Examine a sample of system configuration settings to verify that default security settings are not used for wireless connections.

Examine supporting documentation to verify that the vendor validates any wireless access points that contain flash memory at least once each month to ensure that the firmware contains the authorized software version and appropriate updates.

Examine a sample of evidentiary matter to verify that validation of wireless access points that contain flash memory occurs at least once each month to ensure that the firmware contains the authorized software version …
Added p. 40
Examine a sample of logs of media access-control addresses and associated devices to verify they include at least the make, model, owner, and reason for access.

Interview personnel to verify that a check of authorized media access-control addresses on the access point (AP) is conducted at least quarterly.

Examine a sample of scan reports and verify that checks of authorized media access-control addresses on the access point (AP) occur at least quarterly.

Interview responsible personnel to verify the use of ACLs for access control of clients.

Examine supporting documentation to verify a media access control address-based access-control list (ACL) is used for access control of clients.

Examine a sample of configurations and scan reports to verify that, where capable, Wi-Fi Protected Access (WPA) is enabled.

Observe a sample via the system administrator’s help to verify that default passwords on the AP are changed.

Examine configurations and verify that the management feature for the access point is disabled …
Added p. 41
Examine policies and procedures to verify that quarterly external network vulnerability scans using an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC) are required.

Examine a sample of external vulnerability scans and verify that quarterly external vulnerability scans occurred in the most recent 12-month period and were completed by a PCI SSC Approved Scanning Vendor (ASV).

Examine policies and procedures to verify that internal and external network vulnerability scans are required at least quarterly and after any significant change in the network.

Examine a sample (including the most recent significant change in the network) of internal and external network vulnerability scans to verify scans occur at least quarterly and after any significant change in the network.

c) Ensure all findings from network vulnerability scans are prioritized and tracked. Corrective action for high-priority vulnerabilities must be started within two working days.

Interview responsible personnel to verify that all findings …
Added p. 41
Examine policies and procedures to verify that internal and external penetration tests are performed at least once a year and after any significant infrastructure changes.

Examine the most recent internal and external penetration tests to verify that the following requirements, at a minimum, were met:

i. The internal penetration test must not be performed remotely.

• The internal penetration test was not performed remotely.

Interview responsible personnel to verify evidence of successful remediation is retained and available upon request.
Added p. 42
• Penetration tests were performed on the network layer and included all personalization network components as well as operating systems.

iii. Penetration tests must be performed on the application layer and must include at least the following:

− Injection flaws•e.g., SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

− Buffer overflow − Insecure cryptographic storage − Improper error handling − Insecure communications − All other discovered “high-risk” network vulnerabilities with criteria for ranking vulnerabilities, including:

• Consideration of the Common Vulnerability Scoring System (CVSS) base score, and/or

• The classification by the vendor, and/or

• Type of systems affected.

• Penetration tests were performed on the application layer and included at least the following:

− Injection flaws•e.g., SQL injection − Buffer overflow − Insecure cryptographic storage − Improper error handling − Insecure communications − All other discovered high-risk network vulnerabilities

Interview responsible personnel to verify that all findings from …
Added p. 46
• Ensuring that requests for changes are submitted by authorized users

• Ensuring that requests for changes are submitted by authorized users

• Identification of components that will be changed

• Identification of components that will be changed

• Documentation of impact and back-out procedures

• Documentation of impact and back-out procedures

• Attestation of successful testing, when required

• Attestation of successful testing, when required

• Maintenance of an audit trail of all change requests

• Maintenance of an audit trail of all change requests

• Record of whether or not the change was successful Examine change-control policies and procedures to verify the following are defined:

• Record of whether or not the change was successful

Examine a sample of changes to network and system components to verify changes follow the documented change-management process.

Examine documentation and supporting evidence to verify that the change-management process is validated at least every 12 months.

Examine a sample of changes to network and system components to …
Added p. 47
Examine documented procedures to verify that they include determination of whether applicable patches and updates have become available.

Examine documentation to verify that processes are defined to identify new security vulnerabilities and obtain security patches from appropriate software vendors.

Examine documentation to verify that secure configuration standards are established for all system components.

Examine configuration standards and verify there are requirements to remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

Examine documentation to verify all system components associated with data transmission, storage, and personalization are validated against the authorized configuration monthly.

Examine documentation to verify that all systems used in support of both personalization and cloud- based provisioning networks are actively supported in the form of regular updates.

Examine a sample of system components and related software to:

• Compare the list of security patches installed on each system component to the most recent vendor security-patch list; and

• Verify …
Added p. 48
Examine a sample of system components and related software and compare the list of security patches installed against backup file entries to verify backups are performed.

Observe security control mechanisms for backups and verify they are in place and active.

Interview personnel and review patch update procedures to verify backups are required before applying patches. Identify controls for secure storage.

Examine policies and procedures related to security-patch installation to verify processes are defined for installation of critical patches to Internet-facing system components within 7 business days of release.

Examine a sample of Internet-facing system components and compare the list of security patches installed on each system to the most recent vendor security-patch list, to verify that:

• Applicable, critical vendor-supplied security patches are installed within 7 days of release.

• Supporting documentation is in place recording that the CISO, IT Security Manager, and IT director understand and accept the risk and ensure implementation occurs within 30 …
Added p. 50
Examine evidence that demonstrates monthly verification that systems are meeting the logging requirements.

Interview personnel to ensure they verify at least monthly that systems are meeting the logging requirements.

e) Ensure that logs for all critical and cloud-based provisioning systems are backed up daily, secured, and retained for at least one year. Logs must be accessible for at least three months online and one year offline.

Examine logs for critical and cloud-based provisioning systems to:

• Verify that logs are securely backed up daily.

• Verify that logs are accessible online for at least three months.

• Verify that logs are retained offline for one year.

For both online and backed-up audit logs, review relevant security controls to ensure access is appropriate.

Examine relevant security controls for both online and backed-up audit logs to ensure the ability to modify or delete audit logs is prohibited.

Examine documentation to ensure existence of an incident-response process.

Interview personnel to verify they are …
Added p. 52
Examine data-flow diagrams for personalization data within the environment from the receipt/generation to end of lifecycle.

Interview personnel to verify documentation includes information to support the receipt/generation of data to the end of the lifecycle.

Interview personnel to identify locations of application source code.

Examine system configuration and access control lists to identify users and processes that have access to source code components.

Examine approval records to ensure access to source code was authorized.

Interview personnel to identify in-house developed personalization logs.

Examine log configuration settings to verify restart actions are included.

Examine a sample of personalization logs to verify restart actions (and details associated with that restart event) are captured.

Examine restart procedures to ensure in-house developed personalization software enforces authorization at restart.

Examine policies and procedures to verify a separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

Examine access-control settings to verify that access controls are in place to …
Added p. 54
Interview personnel to verify a software release process exists and is in use.

Examine documentation to verify a quality assurance process is required as part of the software release process and testing of code is performed before software is released.

Examine a sample of recent software updates and identify evidence to verify testing of the code was performed.

Examine policies/procedures to identify testing processes for internally developed software.

Examine documentation to verify it addresses removing temporary code, hard-coded keys, and suspicious code.

Examine a sample of recent internally developed software updates and verify steps to remove temporary code, hard-coded keys, and suspicious code were performed.

Examine policies/procedures to verify they address prevention of debugging within production environment.

Examine configuration standards for PC devices used within the HSA.

Examine a sample of PC devices used in the HSA and obtain evidence that the devices have been configured according to specified configuration standards.

Examine polices/procedures to identify the approval process for …
Added p. 55
Examine policies/procedures to identify change-control processes for software, including the methods used to transfer software from development to production.

Examine a sample of recent software updates and verify steps to transfer software from development to production were performed.

Section 6: User Management and System Access Control 6.1 User Management Requirement Test Procedure The vendor must:

Interview personnel to identify both those authorized to perform, and the processes followed for granting access to vendor’s network, applications, and information.

Examine documented procedures to ensure they address granting access to vendor’s networks, applications, and information.

Examine a sample of recent access requests to verify they were processed by authorized personnel and in accordance with documented procedures.

Examine policies/procedures to ensure they address that:

• Approval and level of access must be restricted to those with a documented business need before access is granted; and

• Documented approvals of access in place must be retained while the account is active.

c) Retain documented …
Added p. 57
Interview security administration personnel to verify access is granted based on least-privilege principles sufficient to perform their duties.

Examine policies/procedures to verify they require that access be granted based on least-privilege principles sufficient to perform their duties.

Examine a sample of recent access requests to verify user access is limited to least privilege and based on documented business need.

Examine policies/procedures for system access to verify they require at least the use of a unique ID and password.

Examine system authentication settings and verify that user IDs in the system are unique and in order to gain access, a password is required.

Interview management to understand the minimum number of administrative user resources required to support the personalization environment.

Examine user ID lists and security privileges to identify users with administrative access and verify the number of users with administrative aligns with management’s expectations.

Examine polices/procedures to verify they require that group, shared, and generic accounts and …
Added p. 58
m) Validate all system access at least quarterly. Interview personnel to verify system access is re-validated at least quarterly.

Examine validation evidence to verify the activity is performed.

Interview personnel to verify card production staff access is revalidated when the employee has a change in duties.

Examine a sample of HR transfer records and verify that revalidation was performed.

o) Ensure that access controls enforce segregation of duties. Interview personnel to identify that policies/procedures support segregation of duties. See glossary definition, “Segregation of Duties,” in the Security Requirements.

Interview personnel and identify controls that restrict issuer access and privileges to only the issuer’s own cardholder data.

Examine access-control settings to ensure access conforms to stated policies.

Interview personnel to identify controls that limit privileged or administrative access.

Examine access-control settings to ensure access confirms to stated policies.

Examine a sample of administrative-access requests and verify access was approved by the user’s manager and IT Security Manager.

Interview personnel to identify …
Added p. 60
c) “First use” passwords expire if not used within 24 hours of distribution.

Examine system configuration settings to verify that first-time passwords are set to expire if not used within 24 hours.

Examine the system configuration settings for a sample of system components to verify that password parameters are set to require a minimum length of at least 12 characters or meet the exception condition.

iv. Special characters Examine the system configuration settings for a sample of system components to verify that user passwords are set to require at least three of the following categories:

f) Passwords are not the same as the user ID. Examine the system configuration settings for a sample of system components to verify passwords cannot be the same as the user ID.

Examine password configurations to verify passwords are encrypted during transmission and rendered unreadable when stored.

Examine a sample of passwords in transit and in storage to verify password values …
Added p. 61
k) The user’s identity is verified prior to resetting a user password. Interview system administration personnel to verify the user’s identity is verified prior to resetting a user password.

Examine password reset procedures to verify the user’s identify is verified prior to resetting a user password.

Observe a password reset request to verify user identify is verified.

Interview personnel and review policies/procedures to identify controls that protect authentication credential to the tokenization process.
Added p. 61
Examine the system configuration settings for a sample of system components to verify that system/session inactivity time out has been set to 15 minutes or less.

Observe a user session to verify the user is logged out after 15 minutes, if the system does not permit session locking.

Interview personnel to verify a manual log-out process is defined and in use when mechanisms do not exist to automatically log off a user.
Added p. 61
Examine user accounts to verify that any inactive accounts over 90 days old are either removed or disabled.
Added p. 62
Examine the system configuration settings for a sample of system components to verify that authentication parameters are set to require that user accounts be locked out after not more than six invalid logon attempts.

Examine documented procedures to verify that accounts can only be unlocked by either the security administrator or other authorized individual, or via an automated password reset mechanism.

Interview administrators to verify that an account is unlocked only after the identity of the user is verified.

Examine polices/procedures for automated password reset mechanisms to verify they require conformance to the stipulated criteria.

Observe the mechanism including the challenge/response criteria, for accounts that can be unlocked via an automated reset mechanism, to verify the questions are designed as stipulated in the requirement.

d) A user’s account must be locked immediately upon that user leaving the vendor’s employment until it is removed.

Examine policies/procedures to verify that user access is locked when the user leaves …
Added p. 64
•is strictly prohibited.

Examine the software configuration

•for example, shell scripts, command files, communication scripts, software code etc.

•for a sample of system components to verify that cryptographic keys are not embedded.

Examine a sample of key-management audit trails to verify existence.

Examine documented key-management policies and procedures verify that all functions are performed by vendor or issuer staff.

Interview responsible personnel to verify that all functions are performed by vendor or issuer staff.

Examine documented procedures and processes to verify that only authorized personnel have the ability to perform key-management activities.

Interview responsible personnel to ensure they have undergone relevant training for the key- management functions they perform.

Examine documentation to identify digital certificates used in conjunction with cloud-based provisioning products or services.

Interview personnel to verify the certificates have been issued either from a trusted Certificate Authority (CA) or directly under an issuer or application provider PKI.

• Function Interview personnel to verify that key-management activities are documented and …
Added p. 67
d) Public keys must have their authenticity and integrity ensured. In order to ensure authenticity and integrity, a public key must be encrypted, or if in plaintext form, must exist only in one of the following forms:

Examine documented procedures for public keys to verify that public keys must exist only in one of the following forms:

• Within a certificate,

• With an associated MAC (message authentication code) created using the algorithm defined in ISO 16609.

Interview responsible personnel to verify that the implemented method(s) ensure the authenticity and integrity of public keys.

• The payment system specification for asymmetric keys Examine documentation to identify requirements for obtaining an issuer certificate and the associated payment system(s) specifications.

Examine for a sample of asymmetric keys evidence to verify requirements were met.
Added p. 67
Examine documented procedures to verify that procedures for transferring key-management roles between individuals are defined.

Interview responsible personnel in applicable key-management roles to verify they are aware of and are following the documented procedures.
Added p. 68
Examine documented procedures to verify that access to physical equipment associated with key- management activity is managed such that no single person is able to access or perform key- management functions.

Observe the process of accessing physical equipment to verify that dual control is required to access or perform key-management functions.

Examine documentation to verify the Key Manager has overall responsibility for all activities relating to key management.

Examine approval authorization documentation to verify CISO (or delegate) approved the Key Manager.

i. Have a nominated deputy. Interview the Key Manager to verify that the Key Manager has a nominated deputy.

Examine documentation to identify the nominated deputy for the Key Manager.

Interview the Key Manager to verify that key-management activity is fully documented.

Examine documented policies and procedures for appropriateness.

Interview the Key Manager to verify that all key-management activity is carried out in accordance with documented procedures.

Examine policies/procedures to identify vetting process for key custodians to ensure …
Added p. 71
Examine key-management documentation including, where necessary, documentation of the secure cryptographic devices to verify that keys and key components are generated using a random or pseudo-random process described in ISO 9564-1 and ISO 11568-5 that is capable of satisfying the statistical tests of NIST SP 800-22 or equivalent.

Interview personnel to verify that:

• Key generation takes place in a secure cryptographic device

•e.g., HSM.

• Key generation takes place in a secure cryptographic device

•e.g., HSM.

• The HSM has achieved PCI approval or FIPS 140-2 Level 3 or higher certification for physical security.

• The HSM has achieved PCI approval or FIPS 140-2 Level 3 or higher certification for physical security.

Examine key-management/device documentation to verify that:

• During key-generation, the HSM utilizes a secure algorithm that complies with Annex A of this document.

Examine key-management documentation to verify that procedures are in place to inspect cables under dual control prior to key-management activity, to ensure disclosure of …
Added p. 72
Interview personnel to verify that split knowledge and dual control are required during the generation of any cryptographic keys in component or share form.

Examine a sample of key-ceremony records and events to verify that split knowledge and dual control are required during the generation of any cryptographic keys in component or share form.

Interview personnel to verify that any printed key components:

• Are created in such a way that they cannot be observed in the creation process by anyone other than the authorized key custodian; and

• Cannot be observed on final documents without evidence of tampering.

Examine procedures to verify that printed key components are created in such a way that the key component cannot be tapped or observed during the process by other than the authorized key custodian and cannot be observed on final documents without evidence of tampering.

Examine key-management documentation to verify that any residue from the printing or generation …
Added p. 72
Interview personnel to verify that any generation of keys is not observable or otherwise accessible in clear text to any other person during the generation process.

Observe a key-generation process (live or demonstration if necessary) to verify procedures are followed.

Interview personnel to verify that key components or shares are placed in pre-serialized, tamper- evident envelopes when not in use by the authorized key custodian.

Examine locations of key components or shares not in use by the authorized key custodian to verify they are contained in pre-serialized, tamper-evident envelopes.

Examine payment system requirements for public-key algorithms regarding the length of issuer key pairs and the vendor’s key-management documentation for consistency.
Added p. 73
Examine key-management documentation and interview personnel to verify:

• The generation of asymmetric key pairs ensures the secrecy of the private key and the integrity of the public key; and

• Their creation and management are in compliance with the payment system requirements for obtaining the issuer certificate.

Examine payment system requirements for the creation and management of asymmetric keys and the vendor’s key-management documentation for consistency.
Added p. 73
a) Keys must be distributed only in their allowable forms. Examine key-management documentation to verify that keys are distributed only in their allowable forms in accordance with Sections 7.2, “Symmetric Keys, and 7.3, “Asymmetric Keys.”

Examine key-management documentation to verify that keys and key components or shares are encrypted prior to electronic transmission.

Examine documentation for conveying key components to verify that the use of different communication channels, such as different courier services and not the same courier on different days, is required.

Examine key-management activity audit logs to verify key components were sent according to required procedures.

Examine procedures for key generation to ensure a two-part form is used and the form identifies the materials sent.

Examine the two-part form to verify that it includes details of the sender and the material sent.

Examine a sample of recently generated key components and verify the forms were adequately signed and returned according to procedures.
Added p. 74
Examine policies/procedures to verify that key components or shares are placed in pre-serialized TEE bags prior to shipment.

Examine a sample of key-management activity logs and verify that pre-serialized numbers are logged as part of the process.

Examine key-management policies/procedures to verify that inspection of the shipping package received is required and that any signs of tampering require initiation of key-compromise procedures.

Examine procedures for key-component receipt to verify a two-part form is used and the form identifies the materials sent.

Examine procedures for key-component receipt to verify that one part of the form is returned to the sender of the component or share, acknowledging receipt.

iv. Securely store the component or share according to the vendor’s key-storage policy.

Examine procedures for key-component receipt to verify that the component or share is securely stored according to the vendor’s key-storage policy.

Examine key-management documentation to verify that prior to certificate acceptance a prearranged method to validate certificate status …
Added p. 75
Examine key-management documentation to verify that any hardware used in the key-loading function is dedicated, controlled, and maintained in a secure environment under dual control.

Observe any hardware used in the key-loading function to verify it is dedicated, controlled, and maintained in a secure environment and under dual control.

Examine documentation to verify that all newly deployed key-loading devices are SCDs and are either PCI-approved or FIPS 140-2 or 140-3 Level 3 or higher certification for physical security.

Examine key-management documentation to verify that the target cryptographic devices, cabling, and paper components are inspected for any signs of tampering prior to key loading.

Observe personnel performing physical inspections of the target cryptographic devices, cabling, and paper components to verify processes are followed to detect signs of tampering prior to key loading.

Examine key-management documentation to verify that all key/key component/key share-holding mechanisms used for loading keys, key components, or shares are:

• In the physical possession …
Added p. 76
Examine key-management documentation to verify that all key/key component/key share-holding device used for key loading are managed under dual control.

Observe personnel performing key loading to verify that all key/key component/key share-holding mechanisms are handled under dual control.

Examine key-management documentation to verify that the key-loading process does not disclose any portion of a key component/share to an unauthorized individual.

Examine key-management documentation to verify that any key component/share that is human- readable is only visible:

• At one point in time to the key custodian, and

• For the duration of time required to load the key.

Examine key-management documentation to verify that for all keys or key components/shares loaded:

• A validation mechanism is in place to ensure authenticity of the keys and key components and provide assurance that the keys and key components have not been tampered with, substituted or compromised;

• If check values are used, they are not the full length of the …
Added p. 77
k) During the key-loading process, key custodians as well as the key manager must verify that the key usage set for the key being loaded matches the keys intended use. This information must be recorded in an audit trail of the key ceremony.

Examine key-management documentation to verify procedures are in place to validate key usage.

Examine key ceremony audit logs to ensure they are complete and correct.

• Key components/shares are stored in pre-serialized, tamper-evident envelopes;

• The envelopes are stored in secure locations (such as safes); and

• Removal of the envelopes from their secure location is detectable.

Observe the envelopes used to verify that they are pre-serialized and tamper-evident.

Observe storage locations to verify the envelopes are stored in separate, secure locations.

b) These envelopes must not be removable without detection. Examine key-management documentation and interview personnel to verify removal of the envelopes from their secure location is detectable.

Examine key-management documentation and interview personnel to …
Added p. 78
Examine key-management documentation for secret or private key component/shares that are stored on a physical media to verify that the key custodian (or designated backup) is the only person allowed possession of both the media and its corresponding access code.

• Serial number of envelope (in/out) Examine key-management documentation to verify that access logs are maintained.

Examine access logs to key component/share storage and verify that they contain:

• Date and time (in/out)

• Names and signatures of the key custodians involved

Examine key-management documentation to verify that logs for access and destruction of master keys are retained until at least after all keys protected by those master keys are retired and no longer in circulation.
Added p. 78
Examine documentation to identify controls that ensure private keys are used only to create digital signatures or perform decryption and that private keys shall not be used to encrypt other keys.
Added p. 78
Examine documentation to identify controls that ensure private keys are used only to create digital signatures or perform decryption; that private keys shall not be used to encrypt other keys; and RSA encryption (public) keys must be prohibited from being used to generate signatures.
Added p. 79
Examine documentation to identify controls that ensure public keys can only be used to verify digital signatures OR perform encryption operations.

Examine policies/procedures to identify controls that KEKs are not used as working keys and vice versa.

Examine evidence that verifies controls are in place and functioning.

Examine documentation to verify it requires that key-encipherment keys are:

• Unique per established key zone

• Only shared between the two communicating entities Interview key custodians and key-management supervisory personnel to verify the implementation of the aforementioned.

Examine key-management documentation to verify that cryptographic keys are only used for the one, specific purpose for which they were defined.

Observe HSM settings and configurations to verify they enforce a separation of keys.

Examine documented key-management policies and procedures to verify that they require that:

• All secret and private keys have a predefined expiry date by which they must be retired from use and cannot be used for a period longer than …
Added p. 80
Examine key-management documentation to verify that keys used for pilots are not used for full product rollout unless the keys were managed to the same level of security compliance as required for production.
Added p. 80
Examine key-management documentation to verify that keys used for prototyping are not used in production.

Examine documented procedures to verify procedures require that the life of key-encrypting keys (KEKs) is shorter than the time required to conduct an exhaustive search of the key space.

Examine documented procedures to verify procedures require that only the algorithms and key lengths stipulated in Normative Annex A of this document be used.

Examine documented procedures to verify that private and secret keys exist in the minimum number of locations consistent with effective system operation.

Examine documented procedures for generating all types of keys and verify the procedures ensure that only unique keys, or sets of keys, are used, and any key variants exist only within the device with the original key.

Examine documented procedures to verify that private keys are only used to decipher or to create a digital signature; and public keys are only used to encipher or …
Added p. 82
Examine documented recovery procedures to verify that recovery of keys requires dual control.

Examine documented procedures and backup records to determine whether any backup copies of keys or their components exist.

Observe back-up processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the production keys.

Examine documented to verify the procedures ensure that the loading of backup keys into failed devices is not permitted until after the reason for that failure has been ascertained and the problem has been corrected.

e) The back-up of keys must conform to Information Security Policy. Examine documented procedures to verify that the back-up of keys conforms to the organization’s Information Security Policy.

Examine documented procedures to verify that all access to all backup storage locations is witnessed and logged under dual control.
Added p. 83
Examine documented procedures to verify processes are in place for destroying keys and their components/shares after successful loading and validation.

Examine a sample of key-history logs and key-destruction logs to verify that all key components/shares have been destroyed immediately upon completion of loading.

Examine storage locations for key components/shares that have been loaded to verify they are no longer present.

Interview personnel to verify that all keying material is rendered irrecoverable (for example, zeroized), or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.

Observe processes for removing cryptographic devices from service to verify that tests and inspections of devices are performed to confirm that keys have been rendered irrecoverable or the devices are physically destroyed.

Examine documented procedures to verify processes are in place for destroying all copies (including backups) of keys that are no longer required.

Examine a sample of key-destruction logs to verify that …
Added p. 84
Examine documented procedures to verify that keys stored on electronic media are:

• Overwritten with random data a minimum of three times, and/or

• Destroyed by smashing so they cannot be reassembled.
Added p. 84
Examine documented procedures for destroying keys to verify that dual control is implemented and key-destruction affidavits are signed by the applicable key custodian for all key-component destruction processes.

Observe a demonstration of processes for removing keys from service to verify that dual control is implemented.

Examine a sample of key-destruction logs and verify that the key custodian signs an affidavit as a witness to the key destruction process.
Added p. 84
• Pre-serialized key envelope number, if applicable Examine key-management logs to verify the following is recorded for each activity:

• The date and time of the activity took place

• The action taken

•e.g., key generation, key distribution, key destruction

• Name and signature of the person performing the action (may be more than one name and signature if split responsibility is involved)

• Countersignature of the Key Manager or CISO (or equivalent)
Added p. 85
Examine documented procedures to verify procedures require key-management logs must be retained for the life span of the key(s) to which they relate.

Examine a sample of key-management logs for different types of keys and verify logs are retained for the life span of the key(s) to which they relate.

Examine documented procedures to ensure access to key-management logs is only permitted for the Key Manager or authorized individuals.

Observe access to a sample of key-management logs to verify it is only permitted to authorized individuals.

Examine documented procedures to ensure procedures restrict access to any capability to reset the sequence number generator or other mechanisms in the HSM.

Examine access-control lists or other processes to verify that only authorized personnel have access to the sequence number generator.

Examine documented procedures to verify the CISO (or equivalent) investigates all audit log validation failures.

Examine documentation to verify an electronic log is maintained to identify keys used during …
Added p. 86
Examine documented procedures for key compromise to verify they include the actions to be taken to protect and/or recover system software and/or hardware, symmetric and asymmetric keys, previously generated signatures, and encrypted data.

Examine documented procedures for key compromise to verify they include requiring an investigation into the cause of the compromise, including a documented analysis of how and why the event occurred and the damages suffered.

Examine documented procedures for key compromise to verify they include that the vendor will remove from operational use all compromised keys within a predefined time frame and provide a means of migrating to new key(s).

Examine documented procedures for key compromise to verify they include that where keys are issuer- owned, the issuer must be notified immediately for further instruction.

Examine documented procedures to ensure replacement keys are not created from a variant of the compromise key.
Added p. 87
Examine documented procedures to verify that in the event of a suspected key compromise, the Key Manager has authority to activate emergency key replacement procedures.

Interview Key Manager to verify he/she is aware of their responsibility and understand the procedures to activate emergency key-replacement procedures.

Examine documented procedures to verify they require that in the event of a suspected key compromise, all instances of the key must be immediately revoked pending the outcome of the investigation.
Added p. 87
Examine documented procedures to verify that all keys encrypted with a key that has been revoked are also revoked.

Examine documented procedures to verify that if a KEK is compromised, the KEK and all keys encrypted with that KEK are replaced.

Examine documented procedures to verify that if a MDK is compromised, the MDK and all keys derived from that MDK are replaced.

Examine documented procedures to verify steps include notification of the VPA within 24 hours of a known or suspected compromise.

Examine documented procedures to verify data items that have been signed with a key that has been revoked are withdrawn as soon as possible and replaced.
Added p. 88
i. All of the HSM’s tamper-resistant mechanisms must be activated. Examine documented procedures to verify that when the HSM is in its normal operational state, all of the HSM’s tamper-resistant mechanisms must be activated.

Observe HSMs in normal operational state to verify they are configured according to the documented procedures, and that all of the HSM’s tamper-resistant mechanisms are activated.

ii. All physical keys must be removed. Examine documented procedures to verify that when the HSM is in its normal operational state, all physical keys must be removed.

Observe HSMs in normal operational state to verify they are configured according to the documented procedures, and that all physical keys are removed.

Examine documented procedures to verify that when the HSM is in its normal operational state, all unnecessary externally attached devices must be removed (such as an operator terminal).

Observe HSMs in normal operational state to verify they are configured according to the documented procedures, …
Added p. 89
Examine documented procedures and logs for HSM installations to verify processes for installation and commissioning of HSMs are documented and logged.

Examine documented procedures for removing HSMs from service to verify that all operational keys are deleted from the device (for example, zeroized) prior to its removal from service.

Observe demonstration of processes for removing HSMs from service to verify all operational keys are deleted from the device.

Examine documented procedures and interview personnel to verify that processes for removal of an HSM for repair or decommissioning must be documented and logged.

Observe processes and examine logs for HSM removal to verify processes for removal of an HSM for repair or decommissioning are documented and logged.

Examine HSM storage locations and records to ensure they have been managed under dual control after receipt.

Section 8: Key Management: Confidential Data 8.1 General Principles Requirement Test Procedure 8.1 General Principles

Examine the documented key hierarchy and verify keys meet …
Added p. 106
For implementations using Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH):

• ECDH implementations entities must securely generate and distribute the system-wide parameters. Entities may generate the elliptic curve domain parameters or use a recommended curve (see NIST SP 800-186). The elliptic curve specified by the domain parameters must be at least as secure as P-224.
Added p. 107
• Each private key shall be statistically unique, unpredictable, and created using an approved random number generator as described in this document.

Asymmetric In cryptography, “asymmetric” implies the use of two different keys: a public key and a private key.

Card Production Staff Employees and contractors of the Card Vendor.
Added p. 110
Facility Facility includes external and internal structures subject to the requirements of Section 2, “Premises,” of the Card Production and Provisioning Physical Security Requirements, even if the vendor is leasing the space.

Media Any storage device used to place, keep, and retrieve data. The format used can include but is not limited to physical

•e.g., paper

•and electronic devices

•e.g., chips, USB devices, tapes, disks.

Multi-factor Authentication Method of authenticating a user when two or more factors are verified. These factors include something the user has (such as a smart card or dongle), something the user knows (such as a password, passphrase, or PIN), or something the user is or does (such as fingerprints, other forms of biometrics, etc.).
Added p. 112
Non-console access Refers to logical access to a system component that occurs over a network interface rather than via a direct, physical connection to the system component. Non-console access includes access from within local/internal networks as well as access from an external, or remote, network.

Participating Payment Brand A payment card brand that, as of the time in question, is then formally admitted as (or an affiliate of) a member of PCI SSC pursuant to its governing documents. At the time of this publication, Participating Payment Brands include PCI SSC’s Founding Members and Strategic Members.

d) Indent printing Personalization file A file created by the issuer or issuer’s processor that has all of the necessary information to personalize a card.

Private Network Network established by an organization that uses private IP address space. Private networks are commonly designed as local area networks. Private network access from public networks should be properly protected with …
Added p. 115
• Security techniques

• Encryption algorithms

• Part 3: Block ciphers.
Modified p. 1
Payment Card Industry (PCI) Card Production and Provisioning Logical Security Requirements Version 2.0
Payment Card Industry (PCI) Card Production and Provisioning Logical Security Requirements and Test Procedures Version 3.0
Removed p. 3
July 2016 2.x PCI RFC Version
Modified p. 3 → 2
December 2012 1.x PCI RFC version
December 2012 1.x RFC version
Modified p. 3 → 2
May 2013 1.0 PCI Initial Release
May 2013 1.0 Initial Release
Modified p. 3 → 2
March 2015 1.1 PCI Enhancements for clarification
March 2015 1.1 Enhancements for clarification
Modified p. 7 → 6
Perform cloud-based or secure element (SE) provisioning services; Manage over-the-air (OTA) personalization, lifecycle management, and preparation of personalization data; or Manage associated cryptographic keys.
Manage over-the-air (OTA) personalization, lifecycle management, and preparation of personalization data; or
Modified p. 7 → 6
Wherever the requirements specify personalization, the requirements also apply to cloud-based provisioning networks (e.g., those for host card emulation). Cloud-based systems differ from those based on requiring the use of a secure element on a mobile device.
Wherever the requirements specify personalization, the requirements also apply to cloud-based provisioning networks⎯e.g., those for host card emulation. Cloud-based systems differ from those based on requiring the use of a secure element on a mobile device.
Modified p. 7 → 6
Although this document frequently states vendor, the specific applicability of these requirements is up to the individual payment brands; and the payment brand(s) of interest should be contacted for the applicability of these requirements to any card production or provisioning activity.
Although this document frequently states “vendor,” the specific applicability of these requirements is up to the individual payment brands; and the payment brand(s) of interest should be contacted for the applicability of these requirements to any card production or provisioning activity.
Modified p. 8 → 7
The individual payment brands are responsible for defining and managing compliance programs associated with these requirements. Contact the Payment Brand(s) of interest for any additional criteria.
The individual Participating Payment Brands are responsible for defining and managing compliance programs associated with these requirements. Contact the Payment Brand(s) of interest for any additional criteria.
Removed p. 9
Information security personnel Assignment of security duties 2.1 Information Security Personnel
Modified p. 9 → 8
a) The vendor must designate, in writing, a senior manager with adequate security knowledge to be and security of the cloud-based provisioning platform. These requirements refer to this person as th
a) The vendor must designate, in writing, a senior manager with adequate security knowledge to be responsible for the vendor’s Information Security Management and security of the cloud-based provisioning platform. These requirements refer to this person as the “Chief Information Security Officer” (“CISO”).
Modified p. 9 → 8
b) The CISO must be an employee of the vendor.
b) The CISO must be an employee of the vendor. Examine employment documentation to verify employment and position.
Modified p. 9 → 8
i. Be responsible for compliance to these requirements.
i. Be responsible for compliance to these requirements. Interview the CISO and examine documentation to determine scope of responsibility.
Modified p. 9 → 8
iii. Not perform activities that they have the responsibility for approving.
iii. Not perform activities that he or she has the responsibility for approving.
Modified p. 9 → 8
iv. Designate a back-up person who is qualified and empowered to act upon critical security events in the event the CISO is not available.
iv. Designate a backup person who is empowered to act upon critical security events in the event the CISO is not available.
Modified p. 9
v. Identify an IT security manager (if not themselves) security environment.
v. Identify an IT Security Manager (if not themselves) responsible for overseeing the vendor’s security environment.
Modified p. 10
a) The vendor must define and document an information security policy (ISP) for the facility.
a) The vendor must define and document an information security policy (ISP) for the facility and disseminate to all relevant personnel (including vendors, sub-contractors, and business partners).
Modified p. 10
c) The ISP must inclu management and enforcement of that policy.
The policy owner is responsible for management and enforcement of that policy.
Modified p. 10 → 12
- Date and time of incident
Date and time of incident
Modified p. 10 → 12
- Details of companies and persons involved
Details of companies and persons involved
Modified p. 10 → 12
- Details of the investigation
Details of the investigation
Modified p. 11 → 12
- Name, e-mail, and telephone number of the person reporting the loss or theft
Name, e-mail, and telephone number of the person reporting the loss or theft
Modified p. 11 → 12
- Name, e-mail, and telephone number of the person to contact for additional information (if different from the person reporting the incident)
Name, e-mail, and telephone number of the person to contact for additional information (if different from the person reporting the incident) Examine ISP documentation to verify notification procedures for suspected compromise of confidential or secret data to the VPA and impacted issuers are in place and requires reporting within 24 hours.
Modified p. 12 → 13
The vendor must maintain detailed procedures relating to each activity in this section.
Section 3: Data Security The data security requirements in this and embedded sections apply to confidential and secret data. The vendor must maintain detailed procedures relating to each activity in this section.
Modified p. 13 → 14
All payment data must have an identifiable owner who is responsible for classification and for ensuring protection controls are implemented and working.
b) All payment data must have an identifiable owner who is responsible for classification for ensuring protection controls are implemented and working.
Modified p. 13 → 14
b) Encrypted at all times during transmission and storage.
b) Encrypted at all times during transmission and storage. Interview personnel to identify controls in place for the transmission and storage of secret and confidential data.
Modified p. 13 → 15
d) The vendor must only decrypt or translate cardholder data on the data-preparation or personalization or cloud-based provisioning network and not while it is on an Internet or public facing network.
d) The vendor must only decrypt or translate cardholder data on the data-preparation or personalization or cloud-based provisioning network and not while it is on an Internet- or public facing network.
Modified p. 13 → 15
a) Document and follow procedures
a) Document and follow procedures describing the vendor’s data access requirements.
Modified p. 13 → 15
b) Prevent direct access to cardholder data from outside the cloud-based provisioning network or the personalization network.
b) Prevent direct access to cardholder data from outside the cloud- based provisioning network or the personalization network.
Modified p. 13 → 15
c) Prevent physical and logical access from outside the high security area (HSA) to the data- preparation or personalization networks.
c) Prevent logical access from outside the high security area (HSA) to the data-preparation or personalization networks.
Modified p. 13 → 15
e) Establish proper user authentication prior to access.
e) Establish proper user authentication prior to access. Examine documentation to determine whether user authentication procedures are defined.
Modified p. 13 → 16
g) Ensure that PANs are masked when displayed or printed unless there is a written issuer authorization. When PANs are masked, only a maximum of the first six and last four digits of the PAN can be visible. Business requirements must be documented and approved by the issuer. PANs must be encrypted at all other times and decrypted only for the minimum time required for processing.
g) Ensure that PANs are masked when displayed or printed unless there is a written issuer authorization. When PANs are masked, only a maximum of the first six and last four digits of the PAN can be visible. Business requirements must be documented and approved by the issuer.
Modified p. 14 → 17
a) Data transmission procedures must incorporate the maintenance of a transmission audit log that includes, at a minimum:
a) Cardholder data transmission procedures must incorporate the maintenance of a transmission audit log that includes, at a minimum:
Modified p. 14 → 17
b) Data transmitted to or received from an external source, or transferred on the cloud-based provisioning network must be encrypted and decrypted per the Encryption Requirements of this document.
b) Cardholder data transmitted to or received from an external source or transferred on the cloud-based provisioning network must be encrypted and decrypted per the encryption requirements of this document.
Modified p. 14 → 17
c) The vendor must establish mechanisms that ensure the authenticity and validate the integrity of data transmitted and received.
c) The vendor must establish mechanisms that ensure the authenticity and validate the integrity of cardholder data transmitted and received.
Modified p. 14 → 17
e) The vendor must accept data only from pre-authorized sources.
e) The vendor must accept cardholder data only from pre-authorized sources that are defined and documented.
Modified p. 14 → 17
g) If the file is not successfully transmitted, or only part of the data is received, the recipient must contact the sender to resolve. The vendor must inform the issuer or authorized processor as soon as possible that the file was not successfully received. Any incomplete data transmission received must be deleted under dual control and logged accordingly.
g) If the file is not successfully transmitted, or only part of the cardholder data is received, the recipient must contact the sender to resolve. The vendor must inform the issuer or authorized processor upon discovery that the file was not successfully received. Any incomplete cardholder data transmission received must be deleted under dual control and logged accordingly.
Modified p. 14 → 18
a) Ensure that procedures -retention policy are documented and followed.
a) Ensure that procedures that define the vendor’s data-retention policy are documented and followed.
Modified p. 14 → 18
ii. Ensure each issuer authorization to retain data is valid for no longer than two years.
ii. Ensure each issuer authorization to retain cardholder data is valid for no longer than two years.
Modified p. 14 → 18
d) Confirm the deletion of manually deleted data including sign-off by a second authorized person.
d) Confirm the deletion of manually deleted cardholder data including sign-off by a second authorized person.
Modified p. 15 → 18
e) Conduct quarterly audits to ensure that all data beyond the data retention period has been deleted.
e) Conduct quarterly audits to ensure that all cardholder data beyond the data retention period has been deleted.
Modified p. 15 → 18
f) Ensure that all secret or confidential data has been irrecoverably removed before the media is used for any other purpose.
f) Ensure that all cardholder data has been irrecoverably removed before the media is used for any other purpose.
Modified p. 15 → 18
g) Ensure media destruction is performed according to industry standards (see ISO 9564-1:
g) Ensure media destruction is performed under CCTV surveillance according to industry standards (see ISO 9564-1: Personal Identification Number Management and Security) under dual control, and that a log is maintained and signed confirming the destruction process.
Modified p. 15 → 18
Personal Identification Number Management and Security) under dual control and that a log is maintained and signed confirming the destruction process.
log is maintained and signed confirming the destruction process.
Modified p. 15 → 19
h) Ensure data is always stored within the high security area (HSA).
h) Ensure cardholder data is always stored within the high security area (HSA).
Modified p. 15 → 19
i) Ensure that data retained for longer than 30 days after personalization complies with the following additional requirements. This data must:
i) Ensure that cardholder data retained for longer than 30 days after personalization complies with the following additional requirements. This data must:
Modified p. 15 → 19
a) The vendor must have a documented removable-media policy that includes laptops, mobile devices, and removable storage devices e.g., USB devices, tapes and disks.
a) The vendor must have a documented removable-media policy that includes laptops, mobile devices, and removable storage devices• e.g., USB devices, tapes, and disks.
Modified p. 15 → 19
b) All removable media (e.g., USB devices, tapes, disks) within the HSA must be clearly labeled with a unique identifier and the data classification.
b) All removable media •e.g., USB devices, tapes, disks

•within
the HSA must be clearly labeled with a unique identifier and the data classification.
Modified p. 15 → 20
e) A log must be maintained when media is removed from or returned to its storage location, or transferred to the custody of another individual. The log must contain:
e) A log must be maintained when media is removed from or returned to its storage location or transferred to the custody of another individual. The log must contain:
Modified p. 15 → 20
iv. Name and signature of recipient custodian
Name and signature of the current custodian
Modified p. 15 → 20
v. Reason for transfer
Reason for transfer
Modified p. 16 → 20
a) Ensure personalization signals cannot be detected beyond the HSA.
a) Ensure personalization signals cannot be detected beyond the HSA. Examine evidence to verify testing was performed showing that contactless personalization signals cannot be detected external to the HSA.
Removed p. 17
Figure 5-1 The diagram above shows a typical network setup of a vendor environment and a generic connection from the data source to the machines on the production floor.

Note: The data-preparation and personalization systems may be on the same network.

The following is a brief description of each of the network clouds:
Modified p. 17 → 23
c) All connections to and from the personalization network must be through a system in the
c) All connections to and from the personalization network must be through a system in the DMZ.
Modified p. 17 → 23
d) The DMZ must be located in the Server Room of the HSA.
d) The DMZ must be located in the server room of the HSA. Observe the system components comprising the DMZ to verify it is located in the server room within the HSA.
Modified p. 17 → 24
e) DMZ infrastructure equipment located within the HSA Server Room must be in a dedicated rack with access restricted to the minimum number of authorized individuals.
e) DMZ infrastructure equipment located within the HSA server room must be in a dedicated rack with access restricted to the minimum number of authorized individuals.
Removed p. 18
The following diagrams illustrate acceptable placement of the DMZ and associated firewalls:

Figure 5-3 5.1.4 Data-Preparation Network This is the network that contains the server(s) where the cardholder data is stored pending personalization. This is also the network where the data is prepared and sent to the production floor.
Removed p. 19
Note: See Appendix B for other topology examples.
Modified p. 19 → 25
d) Document the flow of cardholder and cloud-based provisioning data within the environment from the receipt/generation to end of its lifecycle.
d) Document the flow of cardholder and cloud-based provisioning data within the environment from its receipt/generation to end of its lifecycle. The diagram(s) are kept current and updated as needed upon changes to the environment and must undergo an overall review for accuracy at least every 12 months.
Modified p. 19 → 25
e) Ensure that the personalization and data-preparation systems are on dedicated network(s) independent of the back office (e.g., accounting, human resources, etc.) and Internet- connected networks. A virtual LAN (VLAN) is not considered a separate network.
e) Ensure that the personalization and data-preparation systems are on dedicated network(s) independent of the back office •e.g., accounting, human resources, etc.
Modified p. 19 → 25
f) Systems and applications that make up the cloud-based provisioning network must be physically and logically segregated from other vendor networks and internet-connected networks. For example, in a traditional card vendor environment this could be a separate rack in a server room, or in a provisioning-only entity, housed in a separate room or cage in a data center. It cannot be in the same rack as other servers used for different purposes.
f) Physically and logically segment systems and applications that make up the cloud-based provisioning network from other vendor networks and Internet-connected networks. For example, in a traditional card vendor environment this could be a separate rack in a server room, or in a provisioning-only entity, housed in a separate room or cage in a data center. It cannot be in the same rack as other servers used for different purposes.
Modified p. 19 → 25
g) Put controls in place to restrict, prevent, and detect unauthorized access to the cloud-based and personalization networks. Access from within the high security area to anything other than the personalization or cloud-based networks -
g) Put controls in place to restrict, prevent, and detect unauthorized access to the cloud-based and personalization networks. Access from within the high security area to anything other than the personalization or cloud-based networks must be “read-only.” Examine policies and procedures to verify that:
Modified p. 19 → 25
h) Be able to immediately assess the impact if any of its critical nodes are compromised.
h) Be able to immediately assess the impact if any of its critical connecting points are compromised.
Modified p. 19 → 25
i) sion to any system external to the personalization network to only pre-approved functions that have been authorized by the VPA, except for systems in the dedicated DMZ. These write functions must not transmit cardholder data if this involves direct write from the system containing the information.
i) Have controls in place to restrict “write” permission to any system external to the personalization network to only pre-approved functions that have been authorized by the VPA, except for systems in the dedicated DMZ. These write functions must not transmit cardholder data if this involves direct write from the system containing the information.
Modified p. 19 → 26
m) Ensure a process is in place for updates and patches and identification of their criticality, as detailed in Section 6.3.
m) Ensure a process is in place for updates and patches and identification of their criticality, as detailed in Section 5.3, “Configuration and Patch Management.” Examine documented procedures to verify they include a process for updates and patches that includes identification of their criticality as delineated in the Section 5.3, “Configuration and Patch Management.”
Modified p. 19 → 26
n) Have the capability to detect, isolate, and correct abnormal operations on cloud-based provisioning network systems and on cloud-based provisioning network endpoints on a real- time basis, 24/7.
n) Have the capability to detect, isolate, and correct abnormal operations on cloud-based provisioning network systems and on cloud-based provisioning network endpoints on a real-time basis, 24/7.
Removed p. 20
b) s 2 and 3 above for acceptable configurations).

e) Utilize physically separate firewalls for the aforementioned.

g) Implement appropriate operating-system controls on firewalls.
Modified p. 20 → 27
b) Document the current network device configuration settings, rules set and justification for each device.
b) Document the current network device configuration settings, rulesets, and justification for each device.
Modified p. 20 → 27
f) Implement patches in compliance with Section 6.3, Configuration and Patch Management.
f) Implement patches in compliance with Section 5.3, “Configuration and Patch Management.” Examine a sample of device configurations and verify that patches have been implemented in compliance with Section 5.3.
Modified p. 20 → 27
g) Maintain an audit trail of all changes and the associated approval.
g) Maintain an audit trail of all changes and the associated approval. Examine a sample of change-control logs to verify that an audit trail of changes and associated approvals is maintained.
Modified p. 20 → 27
h) Implement unique IDs for each administrator.
h) Implement unique IDs for each administrator. Examine a sample of administrator IDs and verify that unique IDs are used.
Modified p. 20 → 27
i) Implement network device backups (e.g., system software, configuration data, and database files) prior to any change and securely store and manage all media.
i) Implement network device backups•e.g., system software, configuration data, and database files•prior to any change, and securely store and manage all media.
Modified p. 20 → 28
d) Deploy a firewall between the external network and the DMZ and between the DMZ and the cloud-based provisioning network.
d) Deploy physically separate firewalls between the external network and the DMZ and between the DMZ and the cloud-based provisioning network.
Modified p. 20 → 28
f) Have the capability to detect, isolate, and correct abnormal operations on network systems on a real-time basis, 24/7, on the external (DMZ) facing firewall.
e) Have the capability to detect, isolate, and correct abnormal operations on network systems on a real-time basis, 24/7, on the external (DMZ) facing firewall.
Modified p. 20 → 29
h) Review firewall rule sets and validate supporting business justification either:
g) Review firewall rule sets and validate supporting business justification either:
Modified p. 20 → 29
Monthly, or Quarterly with review after every firewall configuration change.
Quarterly with review after every firewall configuration change.
Removed p. 21
e) If managed remotely, be managed according to .
Modified p. 21 → 29
i) Restrict physical and logical access to firewalls to only those designated personnel who are authorized to perform firewall or router administration activities.
h) Restrict physical and logical access to firewalls to only those designated personnel who are authorized to perform firewall or router administration activities.
Modified p. 21 → 29
j) Ensure the firewall rule set is such that any server only requiring inbound connections (for example, web servers) is prohibited from making outbound connections, and vice versa.
i) Ensure the firewall rule set is such that any server only requiring inbound connections (for example, web servers) is prohibited from making outbound connections, and vice versa.
Modified p. 21 → 29
k) Ensure that only authorized individuals can perform firewall administration.
j) Ensure that only authorized individuals can perform firewall administration.
Modified p. 21 → 29
l) Run firewalls and routers on dedicated hardware. All non-firewall-related software such as compilers, editors, and communication software must be deleted or disabled.
k) Run firewalls and routers on dedicated hardware. All non-firewall- related software such as compilers, editors, and communication software must be deleted or disabled.
Modified p. 21 → 29
m) Implement daily, automated analysis reports to monitor firewall activity.
l) Implement daily, automated analysis reports to monitor firewall activity.
Modified p. 21 → 29
n) Use unique administrator passwords for firewalls used by the personalization system and those passwords used for other network devices in the facility.
m) Use unique administrator passwords for firewalls used by the personalization system and those passwords used for other network devices in the facility.
Modified p. 21 → 30
o) Implement mechanisms to protect firewall and router system logs from tampering, and procedures to check the system integrity monthly.
n) Implement both mechanisms to protect firewall and router system logs from tampering, and procedures to check the system integrity monthly.
Modified p. 21 → 30
p) Explicitly permit inbound and outbound traffic to the cloud-based provisioning and personalization networks. A rule must be in place to deny all other traffic.
o) Explicitly permit inbound and outbound traffic to the cloud-based provisioning and personalization networks. A rule must be in place to deny all other traffic.
Modified p. 21 → 30
a) Be configured to permit network access to required services only.
a) Be configured to permit network access to required services only. Examine policies and procedures for permitting network access to only required services.
Modified p. 21 → 30
d) Implement IP masquerading or Network Address Translation (NAT) on the firewall between the DMZ and personalization and the cloud-based provisioning networks.
Examine policies and procedures for implementing IP masquerading or Network Address Translation (NAT) on the firewall between the DMZ and personalization and the cloud-based provisioning networks to verify existence.
Modified p. 21 → 31
f) Be configured to deny all services not expressly permitted.
f) Be configured to deny all services not expressly permitted. Observe a sample of configuration settings to verify that all services not expressly permitted default to “deny.”
Modified p. 21 → 31
g) Disable all unnecessary services, protocols, and ports. Authorized services must be documented with a business justification and be approved by the IT security manager.
g) Disable all unnecessary services, protocols, and ports. Authorized services must be documented with a business justification and be approved by the IT Security Manager.
Modified p. 21 → 31
h) Disable source routing on the firewall.
h) Disable source routing on the firewall. Examine a sample of firewall configurations to verify that source routing is disabled.
Modified p. 21 → 31
j) Maintain documented baseline security configuration standards for system components based on industry-accepted system hardening standards, which include, but are not limited to: o Center for Internet Security (CIS) o International Organization for Standardization (ISO) o SysAdmin Audit Network Security (SANS) Institute o National Institute of Standards Technology (NIST).
j) Maintain documented baseline security configuration standards for system components based on industry-accepted system hardening standards, which include, but are not limited to:
Removed p. 22
a) Define, document, and follow procedures to demonstrate: o Identification of security alerts e.g., subscribing to security alerts such as Microsoft and the Computer Emergency Response Team (CERT) o Identification of system component updates that affect the supportability and stability of operating systems, software drivers, and firmware components o Inventory of current systems in the environment including information about installed software components and about running services
Modified p. 22 → 32
k) The vendor must perform baseline security configurations checks in the cloud- based provisioning environment either: o Monthly or o Quarterly with review after every configuration change 5.5 Anti-virus software or programs The vendor must:
k) The vendor must perform baseline security configurations checks in the cloud- based provisioning environment either:
Modified p. 22 → 32
b) Deploy anti-virus software on all systems potentially affected by malicious software e.g., personal computers and servers.
b) Deploy anti-virus software on all systems potentially affected by malicious software•e.g., personal computers and servers.
Modified p. 22 → 33
d) Check for anti-virus updates at least daily, and install updates in a manner consistent with Patch Management. Documentation must exist for why any updates were not installed.
d) Check for anti-virus updates at least daily and install updates in a manner consistent with Patch Management. Documentation must exist for why any updates were not installed.
Modified p. 22 → 33
b) Access from outside the facility to the badge access system is not permitted.
b) Access from outside the facility to the physical access-control system is not permitted except as used in conjunction with an approved SOC.
Modified p. 22 → 33
c) Remote access (i.e., from outside the HSA) for administrative-activities is permitted only from pre-determined and authorized locations using vendor-approved systems.
c) Remote access •i.e., from outside the HSA

•for administrative activities
is permitted only from pre-determined and authorized locations using vendor-approved systems.
Modified p. 22 → 33
d) Access using personally owned hardware is prohibited.
d) Access using personally owned hardware is prohibited. Examine policies and procedures to verify that remote access using a personally owned device is prohibited.
Modified p. 22 → 33
e) Remote access is not permitted where qualified employees are temporarily off-site and remote access is a convenience.
e) Remote access is not permitted where qualified personnel are temporarily off-site and remote access is a convenience.
Modified p. 23 → 34
i. System components for which remote access is permitted
i. System components for which remote access is permitted • System components for which remote access is permitted
Modified p. 23 → 34
ii. The location from which remote access is permitted
ii. The location from which remote access is permitted • The location from which remote access is permitted
Modified p. 23 → 34
iii. The conditions under which remote access is acceptable
iii. The conditions under which remote access is acceptable • The conditions under which remote access is acceptable
Modified p. 23 → 34
iv. Users with remote access permission
iv. Users with remote access permission • Users with remote access permission
Modified p. 23 → 34
v. The access privileges applicable to each authorized user
v. The access privileges applicable to each authorized user • The access privileges applicable to each authorized user
Modified p. 23 → 34
iii. Ensure remote changes comply with change-management requirements as outlined in Section 6.2, Change Management.
iii. Ensure remote changes comply with change-management requirements as outlined in Section 5.2, “Change Management.”
Modified p. 23 → 34
iv. Ensure that all remote access locations are included in the facility assessment and meet these requirements.
iv. Ensure that all remote access locations are included in the facility’s compliance assessment and meet these requirements.
Modified p. 23 → 35
k) Ensure that non-vendor staff performing remote administration maintains liability insurance to cover potential losses. All personnel performing remote administration must meet the same pre-screening qualification requirements as employees working in high security areas.
k) Ensure that non-vendor staff performing remote administration maintain liability insurance to cover potential losses. All personnel performing remote administration must meet the same pre-screening qualification requirements as card production staff working in high security areas.
Modified p. 23 → 35
a) For remote access, VPNs must start from the originating device (e.g., PC or off-the-shelf device specifically designed for secure remote access) and terminate at either the target device or the personalization firewall. If the termination point is the firewall, it must use IPSec or at least a TLS connection in accordance with PCI Data Security Requirement 4.1 to the target device.
a) For remote access, VPNs must start from the originating device• e.g., PC or off-the-shelf device specifically designed for secure remote access•and terminate at either the target device or the personalization firewall. If the termination point is the firewall, it must use IPSec or at least a TLS connection in accordance with PCI Data Security Requirement 4.1 to the target device.
Modified p. 23 → 35
c) SSL and TLS 1.0 are expressly prohibited in connection with the aforementioned.
c) SSL and TLS 1.0/1.1 are expressly prohibited in connection with the aforementioned.
Modified p. 23 → 35
e) Modifications to the VPN must be in compliance with the change-management requirements as outlined in Section 6.2, Change Management.
e) Modifications to the VPN must be in compliance with the change- management requirements as outlined in Section 5.2, “Change Management.” Examine a sample of modifications made to VPN configurations and verify that changes are in compliance with the change-management requirements as outlined in Section 5.2, “Change Management.”
Modified p. 24 → 35
f) Mechanisms (e.g., digital signatures, checksums) must exist to detect unauthorized changes to VPN configuration and change-control settings.
f) Mechanisms •e.g., digital signatures, checksums

•must
exist to detect unauthorized changes to VPN configuration and change- control settings.
Modified p. 24 → 35
g) Multi-factor authentication must be used for all VPN connections.
g) Multi-factor authentication must be used for all VPN connections. Examine a sample of VPN system documentation and configuration settings to verify multi-factor authentication is used for VPN connections.
Modified p. 24 → 36
l) VPN traffic using Internet Protocol Security (IPSec) must meet the following additional requirements:
l) VPN traffic using Internet Protocol Security (IPsec) must meet the following additional requirements:
Modified p. 24 → 36
i. Tunnel mode must be used except where communication is host-to-host.
i. Tunnel mode must be used except where communication is host- to-host.
Modified p. 24 → 36
ii. Aggressive mode must not be used for tunnel establishment.
ii. Aggressive mode must not be used for tunnel establishment. • Aggressive mode is not to be used for tunnel establishment.
Modified p. 24 → 37
a) Implement a documented policy regarding wireless communications and clearly communicate this policy to all employees.
a) Implement a documented policy regarding wireless communications and clearly communicate this policy to all card production staff.
Modified p. 24 → 37
d) Use a wireless intrusion-detection system (WIDS) capable of detecting hidden and spoofed networks for all authorized wireless networks.
d) Use a wireless intrusion-detection system (WIDS) capable of detecting hidden and spoofed.
Modified p. 25 → 38
b) Wireless networks must only be used for the transmission of non-cardholder data (e.g., production control, inventory tracking) and be properly secured.
b) Wireless networks must only be used for the transmission of non- cardholder data •e.g., production control, inventory tracking

•and
be properly secured.
Modified p. 25 → 38
d) All wireless gateways must be protected with firewalls.
d) All wireless gateways must be protected with firewalls. Examine a sample of firewall settings and router configurations to verify that wireless gateways are protected with firewalls.
Modified p. 25 → 38
f) All wireless traffic must be encrypted with Triple DES or AES (see Annex A) and an encryption key of at least 128 bits, using WPA, WPA2, or 802.11x (or an equivalent protocol).
f) All wireless traffic must be encrypted with Triple DES or AES and an encryption key of at least 128 bits, using WPA, WPA2, or 802.11x (or an equivalent protocol).
Modified p. 25 → 38
WEP encryption must not be used and must be disabled.
WEP encryption must be disabled.
Modified p. 25 → 39
g) The service set identifier (SSID) must not be broadcast.
g) The service set identifier (SSID) must not be broadcast. Examine system configuration settings to verify that the service set identifier (SSID) is not broadcast.
Modified p. 25 → 39
j) The vendor must disable the SNMP at all wireless access points.
j) The vendor must disable the SNMP at all wireless access points. Examine vendor documentation to verify that SNMP is disabled at all wireless access points.
Modified p. 25 → 39
k) Static passwords used to join wireless networks must be compliant with the requirements in , but may be shared with other individuals in the organization on a need-to-know basis.
k) Static passwords used to join wireless networks must be compliant with the requirements in Section 6.2, “Password Control,” but may be shared with other individuals in the organization on a need-to- know basis.
Modified p. 25 → 39
a) Default SSID must be changed upon installation and must be at least 8 characters.
a) Default SSIDs must be changed upon installation and new passwords must be at least 8 characters.
Modified p. 25 → 40
b) A log of media access-control addresses and associated devices (including make, model, owner, and reason for access) must be maintained, and a check of authorized media access control addresses on the access point (AP) must be conducted at least quarterly.
b) A log of media access-control addresses and associated devices (including but not limited to make, model, owner, and reason for access) must be maintained, and a check of authorized media access-control addresses on the access point (AP) must be conducted at least quarterly.
Modified p. 25 → 40
e) Default passwords on the AP must be changed.
e) Default passwords on the AP must be changed. Examine supporting documentation to verify that default passwords on the AP are required to be changed upon installation.
Removed p. 26
iii. Penetration tests must be performed on the application layer and must include: o Injection flaws (e.g., SQL injection) o Buffer overflow o Insecure cryptographic storage o Improper error handling o All other discovered network vulnerabilities
Modified p. 26 → 42
c) Ensure all findings from network vulnerability scans are prioritized and tracked.
b) Ensure all findings from penetration tests are prioritized and tracked.
Modified p. 26 → 42
b) Ensure all findings from penetration tests are prioritized and tracked. Corrective action for high-priority vulnerabilities must be started within two working days.
Examine a sample of documentation to verify that findings from penetration tests are prioritized and tracked, and that corrective action for high-priority vulnerabilities is started within two working days.
Modified p. 27 → 43
a) Use intrusion-detection systems (IDS) for network traffic analysis. IDS may be implemented as part of an intrusion-prevention system (IPS) if an IPS is used. These must be deployed, managed, and maintained across the vendor networks not only for intrusion detection and prevention but also to monitor all data-preparation and personalization network traffic and cloud-based provisioning networks. This includes all traffic generated by machines within the personalization network. For networks where clear-text PINs traverse, the systems must not be configured …
IDS may be implemented as part of an intrusion-prevention system (IPS) if an IPS is used. These must be deployed, managed, and maintained across the vendor’s networks not only for intrusion detection and prevention but also to monitor all data-preparation and personalization network traffic and cloud-based provisioning networks. This includes all traffic generated by machines within the personalization network, including IDS data from within the DMZ. For networks where clear-text PINs traverse, the systems must not be configured to allow …
Modified p. 27 → 43
b) Ensure the IDS alerts personnel to suspicious activity in real time.
Examine a sample of records to verify the IDS alerts personnel to suspicious activity in real time.
Modified p. 27 → 43
c) Ensure the IDS monitors all traffic at the personalization network perimeter as well as at critical points inside the personalization network.
c) Ensure the IDS monitors all traffic at the personalization network perimeter as well as at critical points inside the personalization network, such as but not limited to firewalls and public-facing interfaces or servers where cardholder data is decrypted.
Removed p. 28
k) Ensure that the badge access is compliant to 6.2 Change Management The vendor must:

a) Ensure that change-control procedures address, at a minimum: o Ensuring that requests for changes are submitted by authorized users o Identification of components that will be changed o Documentation of impact and back-out procedures o Attestation of successful testing, when required o Maintenance of an audit trail of all change requests o Record of whether or not the change was successful
Modified p. 28 → 44
b) Ensure that any system used in the personalization process or in the cloud-based provisioning process is only used to perform its intended function i.e., control personalization or cloud- based provisioning process activities.
b) Ensure that any system used in the personalization process or in the cloud-based provisioning process is only used to perform its intended function•i.e., control personalization or cloud-based provisioning process activities.
Modified p. 28 → 44
c) Change supplier provided default parameters prior to or during installation in the production environment.
c) Change supplier-provided default parameters prior to or during installation in the production environment.
Modified p. 28 → 44
f) Restrict and secure access to system files at all times.
f) Restrict and secure access to system files at all times. Examine access controls to system files to determine that access is restricted.
Modified p. 28 → 44
g) Ensure that virtual systems do not span different network domains.
g) Ensure that virtual systems do not span different network domains. Examine system-architecture documentation and configuration settings to verify that virtual systems do not span different network domains.
Modified p. 28 → 45
i) Ensure that PIN printing takes place on a dedicated network that is either separated from other networks by its own firewall or standalone (i.e., the printer and HSM are integrated) or that the PIN printer is directly attached to the HSM which decrypts the PINs so that it cannot be intercepted.
i) Ensure that PIN printing takes place on a dedicated network that is either separated from other networks by its own firewall or standalone •i.e., the printer and HSM are integrated

•or
that the PIN printer is directly attached to the HSM, which decrypts the PINs so that it cannot be intercepted.
Modified p. 28 → 45
j) Ensure that the badge access-control system complies with the system security requirements in this document.
j) Ensure that the access-control system complies with the system security requirements in this document.
Modified p. 28 → 46
b) Ensure that network and system changes follow a documented change-management process and the process is validated at least every 12 months.
b) Ensure that network and system changes follow a documented change-management process, and that the process is validated at least every 12 months.
Modified p. 29 → 47
f) Ensure all systems used in support of both personalization or cloud-based provisioning networks are actively supported in the form of regular updates.
f) Ensure all systems used in support of both personalization and cloud-based provisioning networks are actively supported in the form of regular updates.
Modified p. 29 → 48
j) Implement critical patches to all Internet-facing system components within 7 business days of release. When this is not possible the CISO, IT security manager, and IT director must clearly record that they understand that a critical patch is required and authorize its implementation within a maximum of 30 business days.
j) Implement critical patches to all Internet-facing system components within 7 business days of release. When this is not possible, the CISO, IT Security Manager, and IT director must clearly record that they understand that a critical patch is required and authorize its implementation within a maximum of 30 business days.
Removed p. 30
i. User identification ii. Type of event iii. Valid date and time stamp iv. Success or failure indication v. Origination of the event vi. Identity or name of the affected data, system component, or resources vii. Access to audit logs viii. Changes in access privileges

e) Ensure that logs for all critical systems and cloud-based provisioning systems are backed up daily, secured, and retained for at least one year. Logs must be accessible for at least three months online and one year offline.
Modified p. 30 → 49
a) Ensure that audit logs exist for all networks and network devices in the vendor environment and for systems and applications connected to the cloud-based provisioning network. This includes operating system logs, security software logs or product logs and application logs containing security events.
a) Ensure that audit logs exist for all networks and network devices in the vendor environment and for systems and applications connected to the cloud-based provisioning network. This includes operating system logs, security software logs, product logs, and application logs containing security events.
Modified p. 30 → 49
c) Ensure that procedures are documented and followed for audit log review and reporting of unusual activity. Log reviews may be automated or manual and must include authentication, authorization, and directory servers. At a minimum, log review frequency must adhere to the following: o Immediate (real time) response to threats designated as alerts for high risk associated o Daily review of IDS and IPS systems o Weekly review for wireless access points and authentication servers o Monthly review for routers …
c) Ensure that procedures are documented and followed for audit log review and reporting of unusual activity. Log reviews may be automated or manual and must include authentication, authorization, and directory servers. At a minimum, log review frequency must adhere to the following:
Modified p. 31 → 51
e) Backups, whether stored within or outside of the HSA, must be encrypted and protected equivalent to the primary data as delineated in Section 4.1, Classification
e) Backups, whether stored within or outside of the HSA, must be encrypted and protected equivalent to the primary data as delineated in Section 3.1, “Classifications.” Interview personnel and review documentation to identify backups and their data classification.
Modified p. 31 → 51
a) Document the design, development, and maintenance processes.
a) Document the design, development, and maintenance processes. Examine documentation of design, development, and maintenance processes to verify existence.
Modified p. 31 → 51
d) Protect any software backup copies from accidental destruction.
d) Protect any software backup copies from accidental destruction. Examine a sample of backups to verify they are adequately protected from accidental destruction.
Modified p. 31 → 52
b) Ensure that in-house-developed personalization software logs any restart (and details associated with that restart event).
b) Ensure that in-house developed personalization software logs any restart (and details associated with that restart event).
Modified p. 31 → 52
c) Ensure that in-house-developed personalization software enforces authorization at restart.
c) Ensure that in-house developed personalization software enforces authorization at restart.
Modified p. 32 → 53
a) Mutual authentication is required. It must be implemented using either client and server X.509 certificates issued and signed by a trusted Certificate Authority (CA) or a VPN constructed in accordance with Section 5.6.2.
a) Mutual authentication is required. It must be implemented using either client and server X.509 certificates issued and signed by a trusted Certificate Authority (CA) or a VPN constructed in accordance with Section 4.6.2, “Virtual Private Network.” Examine documentation for web services for issuer interfaces to identify mutual authentication is used.
Modified p. 32 → 53
b) The most current approved version of TLS is used to secure the connection and requires the following minimum cryptography standards. Refer to the Normative Annex A section of this document for acceptable algorithms and key strengths. o The strongest encryption reasonable must be implemented for the application, if both client and server support higher than these minimum standards. o Implementations must disallow cipher renegotiation within an established TLS session. o Integrity protection must be provided through the use of …
b) The most current approved version of TLS is used to secure the connection and requires the following minimum cryptography standards. Refer to the Normative Annex A section of this document for acceptable algorithms and key strengths.
Modified p. 32 → 53
d) Implement controls to ensure message integrity.
d) Implement controls to ensure message integrity. Examine network documentation to identify controls to support message integrity.
Modified p. 32 → 54
a) Establish and maintain a documented software release process. Quality assurance must include testing of the code for security issues prior to any software releases.
Quality assurance must include testing of the code for security issues prior to any software releases.
Modified p. 32 → 54
c) Ensure all software implementation complies with Section 6.2, Change Management.
c) Ensure all software implementation complies with Section 5.2, “Change Management.” Examine a sample of recent software updates to verify they comply with Section 5.2, “Change Management.”
Modified p. 32 → 54
d) Test software prior to implementation to ensure correct operation.
d) Test software prior to implementation to ensure correct operation. Examine a sample of recent software updates and verify evidence exists that testing software prior to implementation was performed.
Modified p. 32 → 54
e) Prevent debugging within production environment.
e) Prevent debugging within production environment. Interview personnel to identify the controls in place to prevent debugging in the production environment.
Modified p. 32 → 54
h) Ensure no unauthorized software can be installed.
h) Ensure no unauthorized software can be installed. Interview personnel to identify controls established to prevent unauthorized software from being installed.
Removed p. 33
j) Validate all system access at least quarterly.

l) Ensure that access controls enforce segregation of duties.
Modified p. 33 → 56
a) Ensure that procedures are documented and followed by security personnel responsible for
a) Ensure that procedures are documented and followed by security personnel responsible for granting access to vendor’s networks, applications, and information.
Modified p. 33 → 56
b) Restrict approval and level of access to staff with a documented business need before access is granted. At a minimum, documented approvals must be retained while the account is active.
b) Restrict approval and level of access to staff with a documented business need before access is granted.
Modified p. 33 → 56
c) Restrict systems access by unique user ID to only those individuals who have a business need.
d) Restrict systems access by unique user ID to only those individuals who have a business need.
Modified p. 33 → 57
d) Only grant individuals the minimum level of access sufficient to perform their duties.
g) Only grant individuals the minimum level of access sufficient to perform their duties.
Modified p. 33 → 57
e) Make certain that systems authentication requires at least the use of a unique ID and password.
h) Make certain that systems authentication requires at least the use of a unique ID and password.
Modified p. 33 → 57
f) Restrict administrative access to the minimum number of individuals required for management of the system.
i) Restrict administrative access to the minimum number of individuals required for management of the system.
Modified p. 33 → 57
g) Ensure that group, shared, and generic accounts and passwords are disabled wherever the system supports unique values.
j) Ensure that group, shared, and generic accounts and passwords are disabled wherever the system supports unique values.
Modified p. 33 → 57
h) Ensure that where generic administrative accounts cannot be disabled, these accounts are used only when unique administrator sign-on credentials are not possible and only in an emergency.
k) Ensure that where generic administrative accounts cannot be disabled, these accounts are used only when unique administrator sign-on credentials are not possible and only in an emergency.
Modified p. 33 → 57
i) Ensure that when generic administrative accounts are used, the password is managed under dual control where no individual has access to the full password. Each component of the password must comply with the password control requirements in Section 7.2 below.
l) Ensure that when generic administrative accounts are used, the password is managed under dual control where no individual has access to the full password. Each component of the password must comply with the password control requirements in Section 6.2 below except for password length when an exception condition exists..
Modified p. 33 → 58
k) Revalidate employee access to any systems upon a change of duties.
n) Revalidate card production staff access to any systems upon a change of duties.
Modified p. 33 → 58
m) For cloud-based provisioning, restrict issuer access and privileges to own cardholder data.
p) For cloud-based provisioning, restrict issuer access and privileges to only the issuer’s own cardholder data.
Modified p. 33 → 58
n) Strictly limit privileged or administrative access and ensure such access is approved by both IT security manager.
q) Strictly limit privileged or administrative access and ensure such access is approved by both the user’s manager and the IT Security Manager.
Modified p. 33 → 58
o) Establish management oversight of privileged access to ensure compliance with segregation of duties.
r) Establish management oversight of privileged access to ensure compliance with segregation of duties.
Modified p. 33 → 58
p) Ensure that all privileged administrative access is logged and reviewed weekly.
s) Ensure that all privileged administrative access is logged and reviewed weekly.
Removed p. 34
i. Upper-case letters ii. Lower-case letters iii. Numbers iv. Special characters
Modified p. 34 → 59
b) Implement procedures for handling lost, forgotten and compromised passwords.
b) Implement procedures for handling lost, forgotten, and compromised passwords.
Modified p. 34 → 59
c) Distribute password procedures and policies to all users who have access to cardholder information or any system used as part of the personalization process.
c) Distribute password procedures and policies to all users who have access to cardholder data, or any system used as part of the personalization process.
Modified p. 34 → 59
d) Ensure that only users with administrative privileges passwords.
d) Ensure that only users with administrative privileges can administer other users’ passwords.
Modified p. 34 → 60
b) Newly issued passwords are changed on first use.
b) Newly issued passwords are changed on first use. Examine system configuration settings to verify newly issued passwords are changed on first use.
Modified p. 34 → 60
d) Systems enforce password lengths of at least eight characters.
d) Systems enforce password lengths of at least 12 characters, with an exception for operating systems that do not support 12 characters. Passwords can never be less than a minimum length of 8 characters or an equivalent strength.
Modified p. 34 → 60
e) Passwords consist of a combination of at least three of the following:
e) Passwords consist of using a combination of at least three of the following categories:
Modified p. 34 → 60
g) Passwords are not displayed during entry.
g) Passwords are not displayed during entry. Observe authentication procedures for entering a password and verify the password is not displayed as it is entered.
Modified p. 34 → 60
j) When updating passwords, the system prevents users from using a password that is the same as one of their previous four passwords. k)
j) When updating passwords, the system prevents users from using a password that is the same as one of their previous four passwords.
Removed p. 35
d) until it is removed. e) being compromised.
Modified p. 36 → 63
d) Where clear key components or shares pass through a PC or other equipment, the equipment must never be connected to any network and must be powered down when not in use. These computers must dedicated and be hardened and managed under dual control at all times.
d) Where clear key components or shares pass through a PC or other equipment, the equipment must never be connected to any network and must be powered down when not in use. These computers must be dedicated and be hardened and managed under dual control at all times.
Modified p. 36 → 63
e) Keys used for protection of keying material or other sensitive data must meet the minimums delineated in Appendix A.
e) Keys used for protection of keying material or other sensitive data must meet the minimums delineated in Annex A.
Modified p. 36 → 64
g) Cryptographic keys must not be hard-coded into software.
g) Cryptographic keys must not be hard-coded into software. Interview personnel to verify that the embedding of cryptographic keys into software

•for example, in shell scripts, command files, communication scripts, software code etc.
Modified p. 36 → 64
h) Audit trails must be maintained for all key-management activities.
h) Audit trails must be maintained for all key-management activities. Examine policies and procedures to verify that all key-management activities and all activities involving clear-text key components must be logged.
Modified p. 36 → 65
i. Unique identification of the individual that performed each function
Unique identification of the individual that performed each function
Modified p. 36 → 65
iv. Purpose 8.2 Symmetric Keys Ensure that symmetric keys only exist in the following forms:
a) Symmetric keys only exist in the following forms:
Modified p. 36 → 65
a) As plaintext inside the protected memory of a secure cryptographic device
As plaintext inside the protected memory of a secure cryptographic device
Modified p. 36 → 65
c) As two or more full-length components (where each component must be the same length as .
As two or more full-length components (where each component must be the same length as the final key) or as part of an “m of n” sharing scheme where the value of “m” is at least 2.
Modified p. 36 → 65
i. Key components for each specific custodian must be stored in a separate, secure container that is accessible only by the custodian and/or designated backup(s).
b) Key components for each specific custodian must be stored in a separate, secure container that is accessible only by the custodian and/or designated backup(s).
Removed p. 37
iii. As two or more components o managed using the principles of dual control and split knowledge

b) Public keys must have their authenticity and integrity ensured. In order to ensure authenticity and integrity, a public key must be encrypted, or if in plaintext form, must exist only in one of the following forms:

ii. Within a PKCS#10,

iii. Within a SCD, or

ii. The payment system specification for asymmetric keys 8.4 Key-Management Security Administration The secure administration of all key-management activity plays an important role in terms of logical security. The following requirements relate to the procedures and activities for managing keys and key sets.
Modified p. 37 → 66
ii. No single person shall be able to access or use all components or a quorum of shares of a single secret cryptographic key.
c) No single person shall be able to access or use all components or a quorum of shares of a single secret cryptographic key.
Modified p. 37 → 66
i. As plaintext inside the protected memory of a secure cryptographic device
As plaintext inside the protected memory of a secure cryptographic device
Modified p. 37 → 66
iv. Key components for each specific custodian must be stored in a separate, secure container that is accessible only by the custodian and/or designated backup(s).
b) Key components for each specific custodian must be stored in a separate, secure container that is accessible only by the custodian and/or designated backup(s).
Modified p. 37 → 66
v. No single person shall be able to access or use all components or a quorum of shares of a single private cryptographic key.
c) No single person shall be able to access or use all components or a quorum of shares of a single private cryptographic key.
Modified p. 37 → 67
i. Within a certificate,
Within a certificate,
Modified p. 37 → 67
iv. With a MAC (message authentication code) created using the algorithm defined in ISO 16609.
With a MAC (message authentication code) created using the algorithm defined in ISO 16609.
Modified p. 37 → 67
c) Asymmetric keys also adhere to:
e) Asymmetric keys also adhere to:
Modified p. 37 → 67
i. The payment system requirements for obtaining the issuer certificate
The payment system requirements for obtaining the issuer certificate
Modified p. 37 → 67
a) The vendor must define procedures for the transfer of key-management roles between individuals.
a) The vendor must define procedures for the transfer of key- management roles between individuals.
Modified p. 37 → 68
b) All physical equipment associated with key-management activity, such as physical keys, authentication codes, smart cards, and other device enablers as well as equipment such as personal computers must be managed following the principle of dual control.
b) All physical equipment associated with key-management activity, such as physical keys, authentication codes, smart cards, and other device enablers •as well as equipment such as personal computers •must be managed following the principle of dual control.
Modified p. 38 → 68
ii. Be responsible for ensuring that all key-management activity is fully documented.
ii. Own and be responsible for ensuring that all key-management activity is fully documented.
Modified p. 38 → 68
v. Be an employee of the vendor
v. Be an employee of the vendor. This also applies to the deputy key manager.
Modified p. 38 → 69
i. All key custodians have been trained with regard to their responsibilities, and this forms part of their annual security training.
i. All key custodians have been trained with regard to their responsibilities, including incremental changes, and this forms part of their annual security training.
Modified p. 38 → 69
b) The identity of individual custodians must be restricted on a need-to-know basis and may not be made available in generally available documentation.
b) The identity of individual custodians must be restricted on a need-to- know basis and may not be made available in generally available documentation.
Modified p. 38 → 69
c) The suitability of personnel must be reviewed on an annual basis.
c) The suitability of personnel must be reviewed on an annual basis. Examine documentation to verify that primary and backup key custodians are reviewed annually for suitability to the role.
Modified p. 38 → 69
d) They must be employees of the vendor and never temporary staff or consultants.
d) The key custodians must be employees of the vendor and never temporary staff or consultants.
Modified p. 38 → 70
a) If PINs or pass-phrases are stored, a copy of any PIN or pass-phrase, needed to access any device required for any key-management activity, must be stored securely (for recovery purposes).
a) If PINs or pass-phrases are stored, a copy of any PIN or pass- phrase, needed to access any device required for any key- management activity, must be stored securely (for recovery purposes).
Modified p. 39 → 70
b) Only those person(s) who need access to a device must have access to the PIN or pass- phrase for that device.
b) Only those individuals needing access to a device must have access to the PIN or pass-phrase for that device.
Modified p. 39 → 70
c) There must be a defined policy regarding the PINs and pass-phrases needed to access key-management devices. This policy must include the length and character-mix of such PINs and pass-phrases, and the frequency of change.
c) There must be a defined policy regarding the PINs and pass- phrases needed to access key-management devices. This policy must include the length and character-mix of such PINs and pass- phrases, and the frequency of change.
Modified p. 39 → 71
a) Generate keys and key components using a random or pseudo-random process (as described in ISO 9564-1 and ISO 11568-5) that is capable of satisfying the statistical tests of National Institute of Standards and Technology (NIST) PUB 800-22.
a) Generate keys and key components using a random or pseudo- random process (as described in ISO 9564-1 and ISO 11568-5) that is capable of satisfying the statistical tests of National Institute of Standards and Technology (NIST) PUB 800-22.
Modified p. 39 → 71
b) Key generation must take place in a hardware security module (HSM) that has achieved PCI approval or FIPS 140-2 Level 3 or higher certification for physical security.
b) Key generation must take place in a hardware security module (HSM) that has achieved PCI approval or FIPS 140-2 or 140-3 Level 3 or higher certification for physical security.
Modified p. 39 → 71
During operation, the HSM must utilize a security algorithm that complies with payment system requirements as defined in Appendix A.
During operation, the HSM must utilize a security algorithm that complies with payment system requirements as defined in Annex A.
Modified p. 39 → 71
c) Cables must be inspected to ensure disclosure of a plaintext key or key component or share is not possible.
c) Cables must be inspected under dual control to ensure disclosure of a plaintext key or key component or share is not possible.
Modified p. 39 → 72
e) Key components, if printed, must be created in such a way that the key component cannot be cannot be tapped or observed during the process by other than the authorized key custodian. Additionally, the key components cannot be observed on final documents without evidence of tampering.
e) Key components, if printed, must be created in such a way that the key component cannot be tapped or observed during the process by other than the authorized key custodian. Additionally, the key components cannot be observed on final documents without evidence of tampering.
Modified p. 39 → 72
h) Key components or shares must be placed in pre-serialized, tamper-evident envelopes when not in use by the authorized key custodian.
h) Key components or shares must be placed in pre-serialized, tamper- evident envelopes when not in use by the authorized key custodian.
Modified p. 39 → 72
a) Adhere to the public key algorithm and ensure that the length of issuer RSA key pairs used for payment-transaction processing is in accordance with payment-system requirements.
a) Adhere to the public-key algorithm and ensure that the length of issuer RSA key pairs used for payment-transaction processing is in accordance with payment-system requirements.
Modified p. 40 → 73
b) When transmitted electronically, keys and key components or shares must be encrypted prior to transmission following all key-management requirements documented in this section.
b) When transmitted electronically, keys and key components or shares must be encrypted prior to transmission following all key- management requirements documented in this section.
Modified p. 40 → 74
i. Inspect and ensure that no one has tampered with the shipping package. If there are any signs of tampering, the key must be regarded as compromised compromise procedures document must be followed.
i. Inspect and ensure that no one has tampered with the shipping package. If there are any signs of tampering, the key must be regarded as compromised and the vendor’s key-compromise procedures document must be followed.
Modified p. 40 → 75
a) Any hardware used in the key loading function must be dedicated, controlled, and maintained in a secure environment under dual control. Effective January 2018, all newly deployed key- loading devices must be SCDs, either PCI-approved or FIPS 140-2 Level 3 or higher certification for physical security.
a) Any hardware used in the key-loading function must be dedicated, controlled, and maintained in a secure environment under dual control. Effective January 2018, all newly deployed key-loading devices must be SCDs, either PCI-approved or FIPS 140-2 or 140-3 Level 3 or higher certification for physical security.
Modified p. 40 → 75
c) Tokens, PROMs, or other key component/shares mechanisms used for loading keys (or key components/shares) must only be in the physical possession of the designated custodian (or their backup), and only for the minimum practical time.
c) Tokens, PROMs, or other key component/share mechanisms used for loading keys (or key components/shares) must only be in the physical possession of the designated custodian (or their backup), and only for the minimum practical time.
Removed p. 41
iii. Purpose of access
Modified p. 41 → 75
e) All key loading activities must be under the control of the Key Manager.
e) All key-loading activities must be under the control of the Key Manager.
Modified p. 41 → 76
i. Securely destroy or delete it from the key-loading materials as defined in Section 8.11, Key Destruction
Securely destroy or delete it from the key-loading materials as defined in Section 7.11, “Key Destruction”; or
Modified p. 41 → 76
ii. Securely store it according to these requirements if preserving the keys or components/shares for future loading.
Securely store it according to these requirements if preserving the keys or components/shares for future loading.
Modified p. 41 → 77
a) Key components/shares must be stored in pre-serialized, tamper-evident envelopes in separate, secure locations (such as safes).
a) Key components/shares must be stored in pre-serialized, tamper- evident envelopes in separate, secure locations (such as safes).
Modified p. 41 → 77
b) These envelopes must not be removable without detection.
Observe storage locations to verify the envelopes cannot be removed without detection.
Modified p. 41 → 78
d) Where a secret or private key component/share is stored on a token (e.g., an integrated circuit card) and an access code (e.g., a personal identification number (PIN)) or similar access- control backup) must be allowed possession of both the token and its corresponding access code.
d) Where a secret or private key component/share is stored on a •e.g., an integrated circuit card

•and
an access code •e.g., a personal identification number (PIN)) or similar access-control mechanism is used to access that token, only that token’s owner (or designated backup) must be allowed possession of both the token and its corresponding access code.
Modified p. 41 → 78
i. Date and time (in/out)
Date and time (in/out)
Modified p. 41 → 78
ii. Names and signatures of the key custodians involved
Names and signatures of the key custodians involved
Modified p. 41 → 78
iv. Serial number of envelope (in/out)
Serial number of envelope (in/out)
Modified p. 42 → 78
a) Each key must be used for only one purpose and not shared between payment systems, issuers or cryptographic zones, for example:
a) Each key must be used for only one purpose and not shared between payment systems, issuers, or cryptographic zones, for example:
Modified p. 42 → 79
b) Transport keys used to encrypt other keys for conveyance (e.g., KEK, ZCMK) must be unique per established key zone and, optionally, unique per issuer within that zone. These keys must only be shared between the two communicating entities and must not be shared with any third organization.
b) Key-encipherment keys used to encrypt other keys for conveyance •e.g., KEK, ZCMK

•must
be unique per established key zone and, optionally, unique per issuer within that zone. These keys must only be shared between the two communicating entities and must not be shared with any third organization.
Modified p. 42 → 80
ii. Prohibit keys used for pilots (i.e., limited production for example via time, capabilities or volume) from being used for full product rollout unless the keys were managed to the same level of security compliance as required for production.
ii. Prohibit keys used for pilots (i.e., limited production•for example via time, capabilities, or volume) from being used for full product rollout unless the keys were managed to the same level of security compliance as required for production.
Modified p. 42 → 80
iii. Ensure that any keys used for prototyping (i.e., using cards for proof of concept or process where production keys are not used) are not used in production.
iii. Ensure that any keys used for prototyping•i.e., using cards for proof of concept or process where production keys are not used•are not used in production.
Removed p. 43
e) The backup of keys must conform to Information Security Policy.
Modified p. 43 → 81
viii. Maintain an inventory of keys under its management to determine when a key is no longer required e.g., could include key label/name, effective date, expiration date, key purpose/type, key length, etc.
viii. Maintain an inventory of keys under its management to determine when a key is no longer required•e.g., could include key label/name, effective date, expiration date, key purpose/type, key length, etc.
Modified p. 43 → 81
g) All derivation keys must be unique per issuer.
g) All derivation keys must be unique per issuer. Examine key-management documentation to verify that all derivation keys are unique per issuer.
Modified p. 43 → 81
a) Ensure that key backup and recovery are part of the business recovery/resumption plans of the organization.
a) Ensure that key back-up and recovery are part of the business recovery/resumption plans of the organization.
Modified p. 43 → 82
c) All relevant policies and procedures that apply to production keys must also apply to back-up keys.
c) All relevant policies and procedures that apply to production keys must also apply to backup keys.
Modified p. 43 → 82
d) Vendor must prohibit the loading of back-up keys into a failed device until the reason for that failure has been ascertained and the problem has been corrected.
d) Vendor must prohibit the loading of backup keys into a failed device until the reason for that failure has been ascertained and the problem has been corrected.
Modified p. 43 → 82
f) All access to back-up storage locations must be witnessed and logged under dual control.
f) All access to backup storage locations must be witnessed and logged under dual control.
Modified p. 43 → 83
b) When a cryptographic device (e.g., HSM) is decommissioned, any data stored and any resident cryptographic keys must be deleted or otherwise destroyed.
b) When a cryptographic device •e.g., HSM

•is
decommissioned, any data stored and any resident cryptographic keys must be deleted or otherwise destroyed.
Modified p. 44 → 84
j) A person who is not a key custodian for any part of that key must witness the destruction and also sign the key-destruction affidavits, which are kept indefinitely. (This person may also fulfill the dual-presence requirement above or be a third person to the activity.)
j) A person who is not a key custodian for any part of that key must witness the destruction and also sign the key-destruction affidavits, which are kept indefinitely. (This person may also fulfill the dual- presence requirement above or be a third person to the activity.) Observe the key-destruction process and verify that it is witnessed by a person who is not a key custodian for any component of that key; or Examine a sample of key-destruction logs and …
Modified p. 45 → 84
i. The date and time of the activity took place
The date and time of the activity took place
Modified p. 45 → 84
ii. The action taken (e.g., whether key generation, key distribution, key destruction)
The action taken •e.g., whether key generation, key distribution, key destruction
Modified p. 45 → 84
iii. Name and signature of the person performing the action (may be more than one name and signature if split responsibility is involved)
Name and signature of the person performing the action (may be more than one name and signature if split responsibility is involved)
Modified p. 45 → 84
iv. Countersignature of the Key Manager or CISO
Countersignature of the Key Manager or CISO
Modified p. 45 → 84
v. Pre-serialized key envelope number, if applicable
Pre-serialized key envelope number, if applicable
Modified p. 45 → 86
i. Who is to be notified in the event of a key compromise? At a minimum, this must include the CISO, Key Manager, IT Security Manager, and the VPA
i. Who is to be notified in the event of a key compromise? At a minimum, this must include the CISO, Key Manager, IT Security Manager, and the VPA.
Modified p. 45 → 86
ii. The actions to be taken to protect and/or recover system software and/or hardware, symmetric and asymmetric keys, previously generated signatures, and encrypted data
ii. The actions to be taken to protect and/or recover system software and/or hardware, symmetric and asymmetric keys, previously generated signatures, and encrypted data.
Modified p. 45 → 87
c) Where a key compromise is suspected but not yet proven, the Key Manager must have the ability to activate emergency key replacement procedures.
c) Where a key compromise is suspected but not yet proven, the Key Manager must have the ability to activate emergency key- replacement procedures.
Removed p. 46
i. -responsive mechanisms must be activated.
Modified p. 46 → 87
i) Data items that have been signed using a key that has been revoked (e.g., a public-key certificate) must be withdrawn as soon as practically possible and replaced once a new key is in place.
i) Data items that have been signed using a key that has been •e.g., a public-key certificate

•must
be withdrawn as soon as practically possible and replaced once a new key is in place.
Modified p. 46 → 88
a) All key-management activity must be performed using a HSM.
a) All key-management activity must be performed using an HSM. Examine policies/procedures to verify all key-management activity uses an HSM.
Modified p. 46 → 88
c) HSMs used for key management or otherwise used for the protection of sensitive data must be approved by PCI or certified to FIPS 140-2 Level 3, or higher.
c) HSMs used for key management or otherwise used for the protection of sensitive data must be approved by PCI or certified to FIPS 140-2 or 140-3 Level 3 or higher certification for physical security.
Modified p. 46 → 89
f) When a HSM is removed from service permanently or for repair, all operational keys must be deleted from the device prior to its removal.
f) When an HSM is removed from service permanently or for repair, all operational keys must be deleted from the device prior to its removal.
Modified p. 46 → 89
h) The HSM must be under physical dual control at all times.
h) The HSM must be under physical dual control at all times. Examine documented procedures to verify that HSMs must be under physical dual control at all times when accessed or when in any privileged mode.
Modified p. 47 → 90
c) Cryptographic keys must not be hard-coded into software.
c) Cryptographic keys must not be hard-coded into software. Examine documented key-management policies and procedures to verify a policy exists that prohibits hard-coded cryptographic in software.
Modified p. 47 → 90
d) Audit trails must be maintained for all key-management activities.
d) Audit trails must be maintained for all key-management activities. Interview personnel to verify audit trails are maintained for all key-management activities.
Modified p. 47 → 91
g) The vendor must generate keys and key components using a random or pseudo-random process.
g) The vendor must generate keys and key components using a random or pseudo-random process using one of the following:
Modified p. 47 → 91
i) Keys must be stored in a manner that preserves their integrity.
i) Keys must be stored in a manner that preserves their integrity. Observe the storage locations for a sample of keys and verify the storage is adequate to preserve their integrity.
Modified p. 48 → 93
c) The PIN distribution system must perform no other function than PIN distribution, and any sessions established during the distribution (e.g., a telephone call, an e-mail or a SMS message) must be terminated once the PIN has been sent.
c) The PIN distribution system must perform no other function than PIN distribution, and any sessions established during the distribution
Modified p. 48 → 94
k) The PIN distribution system must be able to identify the cardholder from the identification value
k) The PIN distribution system must be able to identify the cardholder from the identification value in the request, and the request must contain the cardholder’s authentication value.
Modified p. 48 → 94
l) The distribution system must not have any way of associating an identification value or
l) The distribution system must not have any way of associating an identification value or authentication value with a specific cardholder’s name, address, or account number.
Modified p. 48 → 94
n) The PIN must only be decrypted immediately before it is passed to the final distribution channel (e.g., the telephone or e-mail system).
n) The PIN must only be decrypted immediately before it is passed to the final distribution channel•e.g., the telephone or e-mail system.
Modified p. 48 → 95
o) The PIN distribution system must not contain any other cardholder data (e.g., PAN, cardholder name).
o) The PIN distribution system must not contain any other cardholder data•e.g., PAN, cardholder name).
Modified p. 49 → 96
Section 2 Roles and Responsibilities All X X X All requirements applicable
Section 1

Roles and Responsibilities All X X X All requirements applicable
Modified p. 49 → 96
Section 3 Security Policy and Procedures All X X X All requirements applicable
Section 2

Security Policy and Procedures All X X X All requirements applicable
Modified p. 49 → 96
Section 5 Network Security All X X X All requirements applicable
Section 4

Network Security All X X X All requirements applicable
Modified p. 49 → 96
Section 6 System Security
Section 3

• Data
Security 3.10 X X X
Modified p. 49 → 97
Section 4 Data Security
Section 5

• System
Security
Modified p. 50 → 97
Section 7 User Management and System Access Control All X X X All requirements applicable
Section 6

User Management and System Access Control All X X X All requirements applicable
Modified p. 50 → 97
Section 8 Key Management: Secret Data All X X X All requirements applicable
Section 7

Key Management: Secret Data All X X X All requirements applicable
Modified p. 50 → 97
Section 9 Key Management: Confidential Data All X X X All requirements applicable
Section 8

Key Management: Confidential Data All X X X All requirements applicable
Modified p. 50 → 97
Section 10 PIN Distribution via Electronic Methods All X X X All requirements applicable
Section 9

PIN Distribution via Electronic Methods All X X X All requirements applicable
Removed p. 59
Minimum key size in number of bits: 112 1024 160 1024/160 128 Key-encipherment keys shall be at least of equal or greater strength than any key that they are protecting. This applies to any key-encipherment keys used for the protection of secret or private keys that are stored or for keys used to encrypt any secret or private keys for loading or transport. For purposes of this requirement, the following algorithms and keys sizes by row are considered equivalent.

For Diffie-Hellman implementations:
Modified p. 59 → 106
DSA/D-H AES Minimum key size in number of bits: 112 1024 160 1024/160 Minimum key size in number of bits: 168 2048 224 2048/224 Minimum key size in number of bits: 3072 256 3072/256 128 Minimum key size in number of bits: 7680 384 7680/384 192 Minimum key size in number of bits: 15360 512 15360/512 256 DES refers to TDES keys with non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key …
Bits of Security DES IFC (RSA) ECC (ECDSA, EdDSA, ECDH, ECMQV) FFC (DSA, DH, MQV) AES 80 112 1024 160 1024/160 • 112 168 2048 224 2048/224 • 128

3072 256 3072/256 128 192

7680 384 7680/384 192 256

15360 512 15360/512 256 DES refers to TDES keys with non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; …
Modified p. 59 → 106
Entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity shall generate a private key x and a public key y using the domain parameters (p, q, g,). Each private key shall be statistically unique, unpredictable, and created using an approved random number generator …
• DH implementations entities must securely generate and distribute the system-wide parameters: generator g, prime number p and parameter q, the large prime factor of (p - 1). Parameter p must be at least 2048 bits long, and parameter q must be at least 224 bits long. Each entity shall generate a private key x and a public key y using the domain parameters (p, q, g).
Modified p. 59 → 107
Entities must authenticate the Diffie-Hellman public keys using either DSA, a certificate, or a symmetric MAC (based on TDES see ISO 16609 Banking Requirements for message authentication using symmetric techniques; Method 3 should be used).
Entities must authenticate the DH or ECDH public keys using DSA, ECDSA, a certificate, or a symmetric MAC (see ISO 16609 •Requirements for message authentication using symmetric techniques. One of the following: MAC algorithm 1 using padding method 3, MAC algorithm 5 using padding method 4, should be used.
Removed p. 61
Asymmetric key and a private key.
Modified p. 61 → 109
Authentication value The data that the PIN-distribution system uses to authenticate the cardholder Bureau A vendor performing card personalization and/or data preparation.
Authentication value The data that the PIN-distribution system uses to authenticate the cardholder.
Modified p. 61 → 109
Check value A computed value which is the result of passing a data value through a non- reversible algorithm. Check values are generally calculated using a cryptographic transformation, which takes as input a secret key and an arbitrary string and gives a cryptographic check value as output. The computation of a correct check value without knowledge of the secret key must not be feasible.
Check value A computed value which is the result of passing a data value through a non-reversible algorithm. Check values are generally calculated using a cryptographic transformation, which takes as input a secret key and an arbitrary string and gives a cryptographic check value as output. The computation of a correct check value without knowledge of the secret key must not be feasible.
Modified p. 62 → 110
Dual control A process of utilizing two or more separate persons operating together to protect sensitive functions or information whereby no single person is able to access or utilize the materials, e.g., a cryptographic key.
Dual control A process of utilizing two or more separate persons operating together to protect sensitive functions or information whereby no single person is able to access or utilize the materials•e.g., a cryptographic key.
Modified p. 62 → 111
Key management The activities involving the handling of cryptographic keys and other related security parameters (e.g., initialization vectors, counters) during the entire life cycle of the keys, including their generation, storage, distribution, loading and use, deletion, destruction, and archiving.
Key management The activities involving the handling of cryptographic keys and other related security parameters •e.g., initialization vectors, counters

•during
the entire life cycle of the keys, including their generation, storage, distribution, loading and use, deletion, destruction, and archiving.
Modified p. 63 → 111
Keying material The data (e.g., keys and initialization vectors) necessary to establish and maintain cryptographic keying relationships.
Keying material The data •e.g., keys and initialization vectors

•necessary
to establish and maintain cryptographic keying relationships.
Modified p. 63 → 111
Mobile Provisioning The personalization (provisioning) of a commercial off-the-shelf (COTS) device, such as an NFC-equipped mobile phone with appropriate cardholder account information. The information is transmitted to the device by a process called over-the-air (OTA) provisioning or, alternatively, over-the-internet (OTI).
Mobile Provisioning The personalization (provisioning) of a commercial off-the-shelf (COTS) device, such as an NFC-equipped mobile phone with appropriate cardholder account information. The information is transmitted to the device by a process called over-the-air (OTA) provisioning or alternatively, over-the-internet (OTI).
Removed p. 64
Remote Access Access to a specific network from a different network.
Modified p. 64 → 113
In the case of an asymmetric signature system, the public key defines the verification transformation. In the case of an asymmetric encipherment system, the public key defines the encipherment transformation. A key that is all members of a pre-specified group.
In the case of an asymmetric signature system, the public key defines the verification transformation. In the case of an asymmetric encipherment system, the public key defines the encipherment transformation. A key that is “publicly known” is not necessarily globally available. The key may only be available to all members of a pre-specified group.
Removed p. 65
Triple Data Encryption Standard (TDES) An algorithm specified in ISO/IEC 18033-3: Information technology Security techniques Encryption algorithms Part 3: Block ciphers.
Modified p. 65 → 114
Sensitive data Data that must be protected against unauthorized disclosure, alteration, or destruction, especially plain-text PINs and cryptographic keys, and includes design characteristics, status information, and so forth.
Sensitive data Data that must be protected against unauthorized disclosure, alteration, or destruction⎯especially plain-text PINs and cryptographic keys⎯and includes design characteristics, status information, and so forth.
Modified p. 65 → 114
Session key A key established by a key-management protocol, which provides security services to data transferred between the parties. A single protocol execution may establish multiple session keys e.g., an encryption key and a MAC key.
Session key A key established by a key-management protocol, which provides security services to data transferred between the parties. A single protocol execution may establish multiple session keys•e.g., an encryption key and a MAC key.
Modified p. 65 → 114
SQL injection SQL injection is a code-injection technique that exploits a security vulnerability in a website's software. This is done by including portions of SQL statements in a web form entry field in an attempt to get the website to pass a newly formed rogue SQL command to the database (e.g., dump the database contents to the attacker).
SQL injection SQL injection is a code-injection technique that exploits a security vulnerability in a website's software. This is done by including portions of SQL statements in a web form entry field in an attempt to get the website to pass a newly formed rogue SQL command to the database⎯e.g., dump the database contents to the attacker.