Document Comparison
P-ROV_MMS_Application.pdf
→
P-ROV_MMS_Solution.pdf
5% similar
42 → 276
Pages
15586 → 128509
Words
411
Content Changes
Content Changes
411 content changes. 315 administrative changes (dates, page numbers) hidden.
Added
p. 10
2. Summary Overview 2.1 P2PE Merchant-Managed Solution Details P2PE MMS name:
Description of P2PE MMS Provider’s business:
Description of the typical use/implementation of this solution (Include specific industries or channels the solution is intended for):
Description of P2PE MMS Provider’s business:
Description of the typical use/implementation of this solution (Include specific industries or channels the solution is intended for):
Added
p. 11
Application Vendor Name: Application Name: Application Version #: PCI SSC Reference #, if applicable 2.4 Other Third-Party Service Provider entities involved in P2PE Merchant-Managed Solution This could include KIFs, CA/RAs, Encryption Management Services and Decryption Management Services who have opted NOT to list with PCI SSC as a P2PE Component and therefore must be assessed fully for each P2PE solution the service is used in. This could also include other third-party service providers in use as applicable, including authorized Integrator/Resellers and such.
Any additional Applications on POI (add rows as needed to report all applications) Application Name: Version # CHD Access? Note: For MMS only, the Application P-ROVs for all applications with access to clear-text account data may be either submitted and accepted by PCI SSC (and will be identified by the PCI SSC listing number at Section 2.3) OR managed and retained internally by the Merchant- Managed Solution Provider in …
Any additional Applications on POI (add rows as needed to report all applications) Application Name: Version # CHD Access? Note: For MMS only, the Application P-ROVs for all applications with access to clear-text account data may be either submitted and accepted by PCI SSC (and will be identified by the PCI SSC listing number at Section 2.3) OR managed and retained internally by the Merchant- Managed Solution Provider in …
Added
p. 13
Model Name/ Number: Bluetooth Ethernet Serial USB Y N Y N Y N Y N Y N Y N Y N Y N 2.6 All other Secure Cryptographic Devices (SCDs) List of all other SCD types used in the P2PE MMS This includes SCDs used to generate or load cryptographic keys, encrypt keys, or sign applications to be loaded onto POI devices, as well as HSMs used in the P2PE decryption environment. Examples include HSMs, key-injection/loading devices (KLDs) and other devices that generate or load keys or sign applications and/or whitelists.
Identifier Type PTS Approval or FIPS #: Manufacturer Model Name/ Number: Model Name/ Number: Location: # of devices per location: Purpose:
Additional details for all HSMs used in the P2PE MMS PTS Approval or FIPS #: Model Name/ Number: Serial Numbers or other identifiers: Hardware #(s): Firmware #(s): Application #(s): Approved Key Function(s):
Identifier Type PTS Approval or FIPS #: Manufacturer Model Name/ Number: Model Name/ Number: Location: # of devices per location: Purpose:
Additional details for all HSMs used in the P2PE MMS PTS Approval or FIPS #: Model Name/ Number: Serial Numbers or other identifiers: Hardware #(s): Firmware #(s): Application #(s): Approved Key Function(s):
Added
p. 14
Complete the following where multiple acquirers or multiple solution providers manage one or more P2PE solutions on the same POI device: identifier Identify other P2PE solutions on the POI Is the other solution already listed, currently being assessed in a separate P2PE assessment, or included with this P2PE assessment? If solution is already listed, provide PCI SSC listing number If solution being assessed separately, identify P2PE assessor company performing assessment (if known) 2.8 Summary of P2PE Compliance Status P2PE Domain Compliant Comments (optional):
Describe the methods or processes used to identify all elements in scope of the P2PE MMS assessment:
Describe how the P2PE assessor confirmed that the scope of the assessment is accurate and covers all components and facilities for the P2PE 3.2 Segmentation at MMS Provider Identify the MMS provider environment(s) that are addressed in the MMS provider’s PCI DSS assessment (e.g., all solution provider environments, decryption environment …
Describe the methods or processes used to identify all elements in scope of the P2PE MMS assessment:
Describe how the P2PE assessor confirmed that the scope of the assessment is accurate and covers all components and facilities for the P2PE 3.2 Segmentation at MMS Provider Identify the MMS provider environment(s) that are addressed in the MMS provider’s PCI DSS assessment (e.g., all solution provider environments, decryption environment …
Added
p. 18
List of all facilities INCLUDED in this solution assessment Description and purpose of facility included in assessment Address of facility List of facilities used in P2PE MMS that were EXCLUDED from this solution assessment* Description and purpose of facility excluded from assessment Address of facility Explanation why the facility was excluded from the assessment Details of any separate assessments performed for the facility, including how the other assessment was verified to cover all components in scope for this solution * Note: Does not include merchant locations.
P2PE Instruction Manual(s) (PIM):
Reference # (optional use) Document Name (Title of the PIM) Version Number of the PIM Document date (latest version date) Which POI types are addressed? (Must align with Section 2.5) P2PE Application Implementation Guide(s) (IG):
Reference # (optional use) Interviewee’s Name Company Job Title 3.9 Device Samples for P2PE Assessment Complete for all sampled devices in the P2PE assessment, including for every POI …
P2PE Instruction Manual(s) (PIM):
Reference # (optional use) Document Name (Title of the PIM) Version Number of the PIM Document date (latest version date) Which POI types are addressed? (Must align with Section 2.5) P2PE Application Implementation Guide(s) (IG):
Reference # (optional use) Interviewee’s Name Company Job Title 3.9 Device Samples for P2PE Assessment Complete for all sampled devices in the P2PE assessment, including for every POI …
Added
p. 22
Domain 1: Encryption Device and Application Management
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1A-1.1 Encryption operations must be performed using a POI device approved per the PCI PTS program (e.g., a PCI-approved PED or SCR), with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed devices in the following characteristics:
<Report Findings Here> 1A-1.1.1 The POI device’s SRED capabilities must be enabled and active.
1A-1.1.1.a Examine the solution provider’s documented procedures and interview personnel to verify that procedures are defined to ensure that SRED capabilities are enabled and active on all POI devices prior to devices being deployed to merchant encryption environments.
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 1A-1.1.1.b For all POI device types used in the solution, review POI device configurations to verify that all POI device types used in the solution have SRED capabilities enabled and …
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 1A-1.1 Encryption operations must be performed using a POI device approved per the PCI PTS program (e.g., a PCI-approved PED or SCR), with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed devices in the following characteristics:
<Report Findings Here> 1A-1.1.1 The POI device’s SRED capabilities must be enabled and active.
1A-1.1.1.a Examine the solution provider’s documented procedures and interview personnel to verify that procedures are defined to ensure that SRED capabilities are enabled and active on all POI devices prior to devices being deployed to merchant encryption environments.
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 1A-1.1.1.b For all POI device types used in the solution, review POI device configurations to verify that all POI device types used in the solution have SRED capabilities enabled and …
Added
p. 23
1A-1.2.b For each POI device type used in the solution, examine the device configuration to verify that it is configured by default to use only SRED-validated account-data capture mechanisms for accepting and processing P2PE transactions.
<Report Findings Here> 1A-1.2.1 All capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant.
1A-1.2.1.a Examine POI configuration and deployment procedures to verify they include either:
Disabling all capture mechanisms that are not SRED validated, or Implementing configurations that prevent all non-SRED validated capture mechanisms from being used for P2PE transactions.
Documented POI configuration and deployment procedures <Report Findings Here> 1A-1.2.1.b Verify that the documented procedures include ensuring that all non- SRED-validated capture mechanisms are disabled or otherwise prevented from being used for P2PE transactions prior to devices being deployed to merchant encryption environments.
Documented procedures …
<Report Findings Here> 1A-1.2.1 All capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant.
1A-1.2.1.a Examine POI configuration and deployment procedures to verify they include either:
Disabling all capture mechanisms that are not SRED validated, or Implementing configurations that prevent all non-SRED validated capture mechanisms from being used for P2PE transactions.
Documented POI configuration and deployment procedures <Report Findings Here> 1A-1.2.1.b Verify that the documented procedures include ensuring that all non- SRED-validated capture mechanisms are disabled or otherwise prevented from being used for P2PE transactions prior to devices being deployed to merchant encryption environments.
Documented procedures …
Added
p. 24
Refer to Section 2.5 “PTS Devices Supported” in the Summary Overview for this documentation. No further reporting required here.
1A-1.4 Clear-text account data must not be disclosed to any component or device outside of the PCI-approved POI device.
1A-1.4.a Examine documented transaction processes and data flows to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.
Documented transaction processes and data flows <Report Findings Here> 1A-1.4.b Using forensic tools and/or other data tracing methods, inspect a sample of transactions to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.
The assessment must match the application in the following characteristics:
Application name Version number 1A-2.1.a For applications on the PCI SSC list of Validated P2PE Applications, review the list and compare to applications used in the solution to verify that the applications match the …
1A-1.4 Clear-text account data must not be disclosed to any component or device outside of the PCI-approved POI device.
1A-1.4.a Examine documented transaction processes and data flows to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.
Documented transaction processes and data flows <Report Findings Here> 1A-1.4.b Using forensic tools and/or other data tracing methods, inspect a sample of transactions to verify that clear-text account data is not disclosed to any component or device outside of the PCI-approved POI device.
The assessment must match the application in the following characteristics:
Application name Version number 1A-2.1.a For applications on the PCI SSC list of Validated P2PE Applications, review the list and compare to applications used in the solution to verify that the applications match the …
Added
p. 25
Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device interfaces or disabled data-capture mechanisms Documented procedures reviewed: <Report Findings Here> Describe how account privilege assignments verified that merchant logical access to POI devices is restricted as follows:
Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device interfaces or disabled data-capture mechanisms <Report Findings Here>
Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device interfaces or disabled data-capture mechanisms <Report Findings Here>
Added
p. 26
Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device interfaces or disabled data-capture mechanisms Identify the sample of POI devices used: <Report Findings Here> Describe how logon to the device using an authorized test merchant account verified that merchant-account logical access meets the following:
Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device interfaces or disabled data-capture mechanisms <Report Findings Here> 1B-1.1.c Observe a sample of POI device configurations and interview responsible personnel to verify that the defined merchant-access requirements are configured for all devices used in the solution.
Responsible personnel interviewed: <Report Findings Here> Identify the sample of POI devices used: <Report Findings …
Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD Cannot enable disabled device interfaces or disabled data-capture mechanisms <Report Findings Here> 1B-1.1.c Observe a sample of POI device configurations and interview responsible personnel to verify that the defined merchant-access requirements are configured for all devices used in the solution.
Responsible personnel interviewed: <Report Findings Here> Identify the sample of POI devices used: <Report Findings …
Added
p. 27
Identify any P2PE Applications at 1A-2.1 that facilitate printing of full PANs on merchant receipts:
<Report Findings Here> Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” in the Summary Overview for documentation of the PCI SSC listing of the P2PE Application (if this testing procedure is applicable):
1B-1.2 All solution-provider personnel with logical access to POI devices deployed in merchant encryption environments must be documented in a formal list and authorized by solution provider management. The list of authorized personnel is reviewed at least annually.
1B-1.2.a Examine documented authorizations to verify:
All personnel with access to devices are documented in a formal list.
All personnel with access to devices are authorized by management.
Documented authorizations reviewed: <Report Findings Here> 1B-1.2.b For a sample of all POI device types, examine account-access configurations to verify that only personnel documented and authorized in the formal list have access to POI devices.
Identify the sample …
<Report Findings Here> Refer to Section 2.3 “Listed P2PE Applications used in the P2PE Solution” in the Summary Overview for documentation of the PCI SSC listing of the P2PE Application (if this testing procedure is applicable):
1B-1.2 All solution-provider personnel with logical access to POI devices deployed in merchant encryption environments must be documented in a formal list and authorized by solution provider management. The list of authorized personnel is reviewed at least annually.
1B-1.2.a Examine documented authorizations to verify:
All personnel with access to devices are documented in a formal list.
All personnel with access to devices are authorized by management.
Documented authorizations reviewed: <Report Findings Here> 1B-1.2.b For a sample of all POI device types, examine account-access configurations to verify that only personnel documented and authorized in the formal list have access to POI devices.
Identify the sample …
Added
p. 29
1B-2.4.a Examine documented identification and authentication procedures to verify secure identification and authentication procedures are defined for remote access to POI devices deployed at merchant encryption environments.
Documented identification and authentication procedures <Report Findings Here> 1B-2.4.b Verify documented procedures include requirements specified at 1B- 2.4.1 through 1B-2.4.3. Identify the P2PE Assessor who confirms that documented procedures include requirements specified at 1B-2.4.1 through 1B- <Report Findings Here> 1B-2.4.1 Individual authentication credentials for all authorized solution-provider personnel that are unique for each merchant.
Note: If a centralized terminal-management system (TMS) is utilized to manage multiple merchant accounts, it is acceptable for the TMS system to only require unique access for each authorized solution-provider employee accessing the TMS instead of requiring unique access per merchant.
1B-2.4.1 Examine device configurations and authentication mechanisms to verify that all authorized solution-provider personnel have individual authentication credentials that are unique for each merchant (or if applicable, per centralized TMS).
Describe how …
Documented identification and authentication procedures <Report Findings Here> 1B-2.4.b Verify documented procedures include requirements specified at 1B- 2.4.1 through 1B-2.4.3. Identify the P2PE Assessor who confirms that documented procedures include requirements specified at 1B-2.4.1 through 1B- <Report Findings Here> 1B-2.4.1 Individual authentication credentials for all authorized solution-provider personnel that are unique for each merchant.
Note: If a centralized terminal-management system (TMS) is utilized to manage multiple merchant accounts, it is acceptable for the TMS system to only require unique access for each authorized solution-provider employee accessing the TMS instead of requiring unique access per merchant.
1B-2.4.1 Examine device configurations and authentication mechanisms to verify that all authorized solution-provider personnel have individual authentication credentials that are unique for each merchant (or if applicable, per centralized TMS).
Describe how …
Added
p. 31
Documented procedures reviewed: <Report Findings Here> 1B-3.3.b Examine security update deployment records and device logs, and interview responsible solution provider personnel and to verify that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors.
Responsible solution provider personnel interviewed: <Report Findings Here> Describe how the security update deployment records and device logs verified that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors.
<Report Findings Here> 1B-3.4 Updates must be delivered in a secure manner with a known chain-of-trust, as defined by the vendor•e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide.
1B-3.4.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor for delivering updates in a secure manner with a known chain-of-trust.
Documented …
Responsible solution provider personnel interviewed: <Report Findings Here> Describe how the security update deployment records and device logs verified that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors.
<Report Findings Here> 1B-3.4 Updates must be delivered in a secure manner with a known chain-of-trust, as defined by the vendor•e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide.
1B-3.4.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor for delivering updates in a secure manner with a known chain-of-trust.
Documented …
Added
p. 32
1B-4.1.a Examine the solution provider’s procedures for troubleshooting customer problems and verify the procedures include:
PAN and/or SAD is never output to merchant environments Collection of PAN and/or SAD only when needed to solve a specific Storage of such data in a specific, known location with limited access Collection of only a limited amount of data needed to solve a specific Encryption of PAN and/or SAD while stored Secure deletion of such data immediately after use Documented solution provider’s procedures for troubleshooting customer problems reviewed:
<Report Findings Here> 1B-4.1.b For a sample of recent troubleshooting requests, observe data collection and storage locations, and interview responsible personnel to verify the procedures identified at 1B-4.1.a were followed.
Identify the sample of recent troubleshooting requests: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the data collection and storage locations for the sample of recent troubleshooting requests verified …
PAN and/or SAD is never output to merchant environments Collection of PAN and/or SAD only when needed to solve a specific Storage of such data in a specific, known location with limited access Collection of only a limited amount of data needed to solve a specific Encryption of PAN and/or SAD while stored Secure deletion of such data immediately after use Documented solution provider’s procedures for troubleshooting customer problems reviewed:
<Report Findings Here> 1B-4.1.b For a sample of recent troubleshooting requests, observe data collection and storage locations, and interview responsible personnel to verify the procedures identified at 1B-4.1.a were followed.
Identify the sample of recent troubleshooting requests: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the data collection and storage locations for the sample of recent troubleshooting requests verified …
Added
p. 38
1D-1.2.2 Confirm the following through interviews with responsible solution provider personnel and by observing an installation/update:
Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control.
Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control.
All new installations and updates to applications are signed prior to installation on the device.
All new installations and updates to applications are signed prior to installation on the device.
Cryptographic signing for new installations and updates to applications is done under dual control.
Cryptographic signing for new installations and updates to applications is done under dual control.
Responsible solution provider personnel interviewed: <Report Findings Here> Describe how the installation/update verified that:
Cryptographic signing processes for applications are followed as specified in the Implementation Guide.
Aligns with 2B-2.2 1D-1.3 Interview solution-provider personnel and observe configuration processes to determine that applications are integrated with any …
Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control.
Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control.
All new installations and updates to applications are signed prior to installation on the device.
All new installations and updates to applications are signed prior to installation on the device.
Cryptographic signing for new installations and updates to applications is done under dual control.
Cryptographic signing for new installations and updates to applications is done under dual control.
Responsible solution provider personnel interviewed: <Report Findings Here> Describe how the installation/update verified that:
Cryptographic signing processes for applications are followed as specified in the Implementation Guide.
Aligns with 2B-2.2 1D-1.3 Interview solution-provider personnel and observe configuration processes to determine that applications are integrated with any …
Added
p. 39
Aligns with 2C-3.1.3 1D-2.1 Interview solution-provider personnel and examine documentation (including a current copy of the Implementation Guide from the application vendor) to confirm the following:
The solution provider retains a current copy of the Implementation Guide.
The solution provider distributes the Implementation Guide to any outsourced integrators/resellers the solution provider uses for the P2PE solution upon obtaining updates from the application vendor.
Solution provider personnel interviewed: <Report Findings Here> Documentation reviewed, in addition to the current copy of the Implementation Guide from the application vendor:
<Report Findings Here> Current Application Vendor Implementation Guide(s) <Report Findings Here>
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s device-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include device-management functions in their P2PE solution …
The solution provider retains a current copy of the Implementation Guide.
The solution provider distributes the Implementation Guide to any outsourced integrators/resellers the solution provider uses for the P2PE solution upon obtaining updates from the application vendor.
Solution provider personnel interviewed: <Report Findings Here> Documentation reviewed, in addition to the current copy of the Implementation Guide from the application vendor:
<Report Findings Here> Current Application Vendor Implementation Guide(s) <Report Findings Here>
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s device-management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include device-management functions in their P2PE solution …
Added
p. 39
Number of devices deployed and any change in numbers since last report.
Added
p. 39
1E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel, and to confirm that the following processes are documented and implemented:
Number of devices deployed and change since last report.
Documented component provider’s procedures reviewed: <Report Findings Here> Responsible component provider personnel interviewed: <Report Findings Here>
Documented component provider’s procedures reviewed: <Report Findings Here> Responsible component provider personnel interviewed: <Report Findings Here>
Number of devices deployed and change since last report.
Documented component provider’s procedures reviewed: <Report Findings Here> Responsible component provider personnel interviewed: <Report Findings Here>
Documented component provider’s procedures reviewed: <Report Findings Here> Responsible component provider personnel interviewed: <Report Findings Here>
Added
p. 40
Number of devices deployed and changed since last report.
Reports reviewed for this testing procedure: <Report Findings Here> 1E-1.2 Manage and monitor changes to encryption-management services and notify the solution provider upon occurrence of any of the following:
Reports reviewed for this testing procedure: <Report Findings Here> 1E-1.2 Manage and monitor changes to encryption-management services and notify the solution provider upon occurrence of any of the following:
Added
p. 40
Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change.
Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change.
Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change.
Added
p. 40
Note that adding, changing, or removing POI device types, P2PE applications, and/or P2PE non-payment software may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
1E-1.2.a Review component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution provider upon occurrence of the following:
1E-1.2.a Review component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution provider upon occurrence of the following:
Added
p. 41
Adding, changing, and/or removing P2PE non-payment software (without access to clear-text account data), including description of change.
Reports reviewed for this testing procedure: <Report Findings Here>
Reports reviewed for this testing procedure: <Report Findings Here>
Added
p. 43
3A-2 The solution provider manages and monitors status reporting from P2PE component providers.
3A-3 Solution provider implements processes to respond to notifications from merchants, component providers and/or third parties, and provide notifications about any suspicious activity involving the P2PE solution.
3A-4 If the solution provider allows a merchant to stop P2PE encryption of account data, the solution provider manages the related process for merchants 3B Third-party management 3B-1 The solution provider facilitates and maintains formal agreements with all third parties contracted to perform P2PE functions on behalf of the solution provider.
3B-2 Solution provider secures any remote access to POI devices deployed at merchant encryption environments.
3B-3 The solution provider implements procedures to protect POI devices and applications from known vulnerabilities and securely update devices.
3B-4 Solution provider implements procedures to secure account data when troubleshooting 3B-5 The P2PE solution provides auditable logs of any changes to critical functions of the POI device(s).
3C Creation and …
3A-3 Solution provider implements processes to respond to notifications from merchants, component providers and/or third parties, and provide notifications about any suspicious activity involving the P2PE solution.
3A-4 If the solution provider allows a merchant to stop P2PE encryption of account data, the solution provider manages the related process for merchants 3B Third-party management 3B-1 The solution provider facilitates and maintains formal agreements with all third parties contracted to perform P2PE functions on behalf of the solution provider.
3B-2 Solution provider secures any remote access to POI devices deployed at merchant encryption environments.
3B-3 The solution provider implements procedures to protect POI devices and applications from known vulnerabilities and securely update devices.
3B-4 Solution provider implements procedures to secure account data when troubleshooting 3B-5 The P2PE solution provides auditable logs of any changes to critical functions of the POI device(s).
3C Creation and …
Added
p. 44
Identification of all parts of the overall solution managed by the solution provider Identification of any parts of the overall solution outsourced to third-party service providers Identification of P2PE controls covered by each third-party service provider.
3A-1.1.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the overall P2PE solution.
Documented procedures reviewed: <Report Findings Here> Relevant personnel interviewed: <Report Findings Here> 3A-1.1.b Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the overall P2PE solution to verify that the document is current.
Documented procedures reviewed: <Report Findings Here> Relevant personnel interviewed: <Report Findings Here> 3A-1.1.c Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the overall P2PE solution to verify that the Identifies all components of the overall solution managed by the solution provider.
Identifies all components of …
3A-1.1.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the overall P2PE solution.
Documented procedures reviewed: <Report Findings Here> Relevant personnel interviewed: <Report Findings Here> 3A-1.1.b Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the overall P2PE solution to verify that the document is current.
Documented procedures reviewed: <Report Findings Here> Relevant personnel interviewed: <Report Findings Here> 3A-1.1.c Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the overall P2PE solution to verify that the Identifies all components of the overall solution managed by the solution provider.
Identifies all components of …
Added
p. 45
What specifically is required Which legal/regulatory entity requires it To which region/country it applies Note that Domain 1 (at 1B-1.1.1) and Domain 2 (at 2A-3.1.2) also include requirements that must be met for any POI device and any P2PE application, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
3A-1.3.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation includes at least the following details about the legal/regulatory obligation:
What specifically is required Which legal/regulatory entity requires it To which region/country it applies Documented solution provider’s procedures reviewed: <Report Findings Here> 3A-1.3.b Perform independent review of, or conduct interviews with responsible solution provider personnel, to verify that the exception to facilitate merchants’ access to full PANs is based on …
3A-1.3.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation includes at least the following details about the legal/regulatory obligation:
What specifically is required Which legal/regulatory entity requires it To which region/country it applies Documented solution provider’s procedures reviewed: <Report Findings Here> 3A-1.3.b Perform independent review of, or conduct interviews with responsible solution provider personnel, to verify that the exception to facilitate merchants’ access to full PANs is based on …
Added
p. 46
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe the processes observed that verified that the solution provider has implemented a methodology for managing and monitoring status reporting from P2PE component providers, including processes for:
Changes in third-party service providers Changes in overall solution architecture 3A-2.2.a Interview responsible personnel and review documentation to verify the solution provider has a formal process for ensuring P2PE controls are maintained when changes to the P2PE solution occur, including procedures for addressing the following:
Changes in third-party service providers Changes in overall solution architecture Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 3A-2.2.b For a sample of changes, verify changes were documented and the solution updated accordingly. Sample of changes reviewed: <Report Findings Here>
Changes in third-party service providers Changes in overall solution architecture 3A-2.2.a Interview responsible personnel and review documentation to verify the solution provider has a formal process for ensuring P2PE controls are maintained when changes to the P2PE solution occur, including procedures for addressing the following:
Changes in third-party service providers Changes in overall solution architecture Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 3A-2.2.b For a sample of changes, verify changes were documented and the solution updated accordingly. Sample of changes reviewed: <Report Findings Here>
Added
p. 47
Physical device breaches Tampered, missing, or substituted devices Unauthorized logical alterations to devices (e.g., configuration, access controls, whitelists) Failure of any device security control Unauthorized use of sensitive functions (e.g., key-management functions) Encryption/decryption failures
Note: “immediate” means promptly or as soon as possible.
3A-3.1 Examine documented procedures and interview personnel to verify processes are implemented to respond to notifications from merchants, component providers, and other third parties about any suspicious activity and provide immediate notification to all applicable parties, including but not limited Physical device breaches Tampered, missing, or substituted devices Unauthorized logical alterations to devices (e.g., configuration, access controls, whitelists) Failure of any device security control Unauthorized use of sensitive functions (e.g., key-management functions) Encryption/decryption failures Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 3A-3.2 Upon detection of any suspicious activity defined at 3B-4.1, the POI …
Note: “immediate” means promptly or as soon as possible.
3A-3.1 Examine documented procedures and interview personnel to verify processes are implemented to respond to notifications from merchants, component providers, and other third parties about any suspicious activity and provide immediate notification to all applicable parties, including but not limited Physical device breaches Tampered, missing, or substituted devices Unauthorized logical alterations to devices (e.g., configuration, access controls, whitelists) Failure of any device security control Unauthorized use of sensitive functions (e.g., key-management functions) Encryption/decryption failures Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 3A-3.2 Upon detection of any suspicious activity defined at 3B-4.1, the POI …
Added
p. 48
The issue has been resolved and P2PE encryption functionality is restored and re-enabled, or The merchant has provided written notification (signed by a merchant executive officer) requesting stopping of P2PE encryption services, according to the solution provider’s procedures (as defined in Requirement 3B-5.1).
Identification of affected device(s), including make, model, and serial number Identification of affected merchant, including specific sites/locations if applicable Date/time of incident Duration of device downtime Date/time that the issue was resolved Details of whether any account data was transmitted from the POI device(s) during the time that encryption was malfunctioning or disabled 3A-3.3 Examine documented procedures and related records, and interview personnel to verify they maintain records of all suspicious activity, including the following details:
Identification of affected device(s), including make, model, and serial Identification of affected merchant, including specific sites/locations if applicable Date/time of incident …
Identification of affected device(s), including make, model, and serial number Identification of affected merchant, including specific sites/locations if applicable Date/time of incident Duration of device downtime Date/time that the issue was resolved Details of whether any account data was transmitted from the POI device(s) during the time that encryption was malfunctioning or disabled 3A-3.3 Examine documented procedures and related records, and interview personnel to verify they maintain records of all suspicious activity, including the following details:
Identification of affected device(s), including make, model, and serial Identification of affected merchant, including specific sites/locations if applicable Date/time of incident …
Added
p. 49
Identification that a failure has occurred Identifying the root cause Determining remediation needed to address root cause Identifying and addressing any security issues that occurred during the failure Updating the solution and/or controls to prevent cause from recurring 3A-3.5.a Interview responsible personnel and review documentation to verify the solution provider has a formal process for any P2PE control failures, including procedures for addressing the following:
Identification that a failure has occurred Identifying the root cause Determining remediation needed to address root cause Identifying and addressing any security issues that occurred during the Implementing controls to prevent cause from recurring Responsible personnel interviewed: <Report Findings Here> Documentation reviewed: <Report Findings Here> 3A-3.6.b For a sample of P2PE control failures, interview personnel and review supporting document to verify that:
Identification occurred.
Corrective actions were implemented and documented.
The solution and/or control was updated …
Identification that a failure has occurred Identifying the root cause Determining remediation needed to address root cause Identifying and addressing any security issues that occurred during the Implementing controls to prevent cause from recurring Responsible personnel interviewed: <Report Findings Here> Documentation reviewed: <Report Findings Here> 3A-3.6.b For a sample of P2PE control failures, interview personnel and review supporting document to verify that:
Identification occurred.
Corrective actions were implemented and documented.
The solution and/or control was updated …
Added
p. 50
Identification of merchant submitting request Date request received Copy of the formal notification from merchant 3A-4.1.2 Observe implemented processes and interview responsible personnel to verify a record of all received requests is maintained and includes:
Identification of merchant submitting request Date initial request received Copy of the formal notification from merchant Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that a record of all received requests is maintained and includes:
Identification of merchant submitting request Date initial request received Copy of the formal notification from merchant <Report Findings Here> 3B-1.1 Solution provider must have formal agreements in place with all third parties that perform P2PE functions on behalf of the solution provider, including:
All functions each third party is responsible for Agreement to maintain P2PE controls for which they are responsible Notification and documentation of any …
Identification of merchant submitting request Date initial request received Copy of the formal notification from merchant Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that a record of all received requests is maintained and includes:
Identification of merchant submitting request Date initial request received Copy of the formal notification from merchant <Report Findings Here> 3B-1.1 Solution provider must have formal agreements in place with all third parties that perform P2PE functions on behalf of the solution provider, including:
All functions each third party is responsible for Agreement to maintain P2PE controls for which they are responsible Notification and documentation of any …
Added
p. 51
All functions each third party is responsible for Maintaining P2PE controls for which they are responsible Notification and documentation of any changes affecting the third party governed by P2PE requirements Notification of any security-related incidents Defining and maintaining appropriate service level agreements (SLAs) Maintaining compliance with applicable P2PE and/or PCI DSS requirements as needed Agreement to provide proof of compliance with P2PE requirements and/or
PCI DSS requirements as needed Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain.
Documented procedures reviewed: <Report Findings Here> 3B-1.1.b If the solution provider utilizes any third parties, examine the business agreements and verify the elements delineated in 3C-1.1.a are present and adequately accounted for.
Identify the P2PE Assessor who confirms that the business agreements for third parties utilized by the solution provider were …
PCI DSS requirements as needed Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain.
Documented procedures reviewed: <Report Findings Here> 3B-1.1.b If the solution provider utilizes any third parties, examine the business agreements and verify the elements delineated in 3C-1.1.a are present and adequately accounted for.
Identify the P2PE Assessor who confirms that the business agreements for third parties utilized by the solution provider were …
Added
p. 52
Notification of any changes to POI devices, P2PE applications, P2PE non- payment software, and/or HSMs per PCI SSC’s process for P2PE Designated Changes to Solutions Details of the change, including reason Updated list of POI devices, P2PE applications, P2PE non-payment software, and/or HSMs used in the solution Evidence of adherence to PCI’s process for P2PE Designated Changes to Identify the P2PE Assessor who confirms that the business agreements for third parties managing SCDs on behalf of the solution provider were reviewed and verified to require all elements at 3B-1.2:
<Report Findings Here> 3C-1.1 The PIM must be developed, maintained, distributed to merchants, and provided to merchants upon request. Content for the PIM must be in accordance with the mandatory PIM Template.
3C-1.1.a Examine the P2PE Instruction Manual (PIM) to verify it covers all related instructions, guidance and requirements as specified in the PIM Template.
Identify the P2PE Assessor who …
<Report Findings Here> 3C-1.1 The PIM must be developed, maintained, distributed to merchants, and provided to merchants upon request. Content for the PIM must be in accordance with the mandatory PIM Template.
3C-1.1.a Examine the P2PE Instruction Manual (PIM) to verify it covers all related instructions, guidance and requirements as specified in the PIM Template.
Identify the P2PE Assessor who …
Added
p. 53
All P2PE applications specified in the PIM are assessed for this solution (per Domain 1) All P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment Identify the P2PE Assessor who confirms that all P2PE applications specified in the PIM are assessed for this solution (per Domain 1) and that all P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment:
<Report Findings Here> 3C-1.1.f Examine the PIM to verify that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2).
Identify the P2PE Assessor who confirms that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2):
<Report Findings Here> 3C-1.1.g Configure each POI …
<Report Findings Here> 3C-1.1.f Examine the PIM to verify that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2).
Identify the P2PE Assessor who confirms that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2):
<Report Findings Here> 3C-1.1.g Configure each POI …
Added
p. 54
- Any changes to the P2PE requirements.
Responsible personnel interviewed: <Report Findings Here> Describe how processes for reviewing and updating the PIM verified that the PIM is updated at least annually, upon changes to the solution or changes to the PCI P2PE requirements, and as needed to keep the document current with any changes to the P2PE solution and any changes to the P2PE requirements:
<Report Findings Here> 3C-1.2.1 Communicate PIM updates to affected merchants, and provide merchants with an updated PIM as needed.
3C-1.2.1.a Examine documented procedures to verify they include communicating PIM updates to affected merchants and providing an updated PIM as needed.
Documented procedures reviewed: <Report Findings Here> 3C-1.2.1.b Observe processes for reviewing and updating the PIM, and interview responsible personnel to verify PIM updates are communicated to affected merchants and an updated PIM is provided to merchants as needed.
Responsible personnel interviewed: <Report Findings Here> Describe how processes for reviewing and …
Responsible personnel interviewed: <Report Findings Here> Describe how processes for reviewing and updating the PIM verified that the PIM is updated at least annually, upon changes to the solution or changes to the PCI P2PE requirements, and as needed to keep the document current with any changes to the P2PE solution and any changes to the P2PE requirements:
<Report Findings Here> 3C-1.2.1 Communicate PIM updates to affected merchants, and provide merchants with an updated PIM as needed.
3C-1.2.1.a Examine documented procedures to verify they include communicating PIM updates to affected merchants and providing an updated PIM as needed.
Documented procedures reviewed: <Report Findings Here> 3C-1.2.1.b Observe processes for reviewing and updating the PIM, and interview responsible personnel to verify PIM updates are communicated to affected merchants and an updated PIM is provided to merchants as needed.
Responsible personnel interviewed: <Report Findings Here> Describe how processes for reviewing and …
Added
p. 55
4A-2 Restrict access between the merchant decryption environment and all other networks/systems.
4B Restrict traffic between the encryption environment and any other CDE 4B-1 Traffic between the encryption environment and any other CDE is restricted.
4C Restrict personnel access between the encryption environment and the merchant decryption environment 4C-1 Merchant in-store (encryption environment) personnel do not have logical access to the decryption environment, any CDEs, or account-data decryption keys.
Domain 4: P2PE Solution Management
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 4A-1.1 Current documentation must be maintained that describes, or illustrates, the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
4A-1.1.a Interview responsible personnel and review documentation to verify that procedures exist for maintaining documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow …
4B Restrict traffic between the encryption environment and any other CDE 4B-1 Traffic between the encryption environment and any other CDE is restricted.
4C Restrict personnel access between the encryption environment and the merchant decryption environment 4C-1 Merchant in-store (encryption environment) personnel do not have logical access to the decryption environment, any CDEs, or account-data decryption keys.
Domain 4: P2PE Solution Management
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 4A-1.1 Current documentation must be maintained that describes, or illustrates, the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
4A-1.1.a Interview responsible personnel and review documentation to verify that procedures exist for maintaining documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow …
Added
p. 56
Note: The decryption environment must exist within a cardholder data environment (CDE).
4A-1.2.a Examine network diagram(s) to verify that decryption systems are located on a network that is dedicated to decryption operations. Network diagram(s) reviewed: <Report Findings Here> 4A-1.2.b Inspect network and system configurations to verify that decryption systems are located on a network that is dedicated to decryption operations. Describe how network and system configurations verified that decryption systems are located on a network that is dedicated to decryption operations:
<Report Findings Here> 4A-1.3 Systems in the decryption environment must be dedicated to performing and/or supporting decryption and key-management operations:
Services, protocols, daemons, etc. necessary for performing and/or supporting decryption operations must be documented and justified.
Functions not required for performing or supporting decryption operations must be disabled or isolated (e.g., using logical partitions) from decryption operations.
Note: Security functions (e.g., logging and monitoring controls) are examples of functions supporting decryption operations. …
4A-1.2.a Examine network diagram(s) to verify that decryption systems are located on a network that is dedicated to decryption operations. Network diagram(s) reviewed: <Report Findings Here> 4A-1.2.b Inspect network and system configurations to verify that decryption systems are located on a network that is dedicated to decryption operations. Describe how network and system configurations verified that decryption systems are located on a network that is dedicated to decryption operations:
<Report Findings Here> 4A-1.3 Systems in the decryption environment must be dedicated to performing and/or supporting decryption and key-management operations:
Services, protocols, daemons, etc. necessary for performing and/or supporting decryption operations must be documented and justified.
Functions not required for performing or supporting decryption operations must be disabled or isolated (e.g., using logical partitions) from decryption operations.
Note: Security functions (e.g., logging and monitoring controls) are examples of functions supporting decryption operations. …
Added
p. 57
Describe how system configurations verified that systems providing authentication services to system components within the decryption environment reside within the decryption environment and are dedicated to supporting the decryption environment:
<Report Findings Here> 4A-1.5 Logical administrative/privileged access to systems within the decryption environment must be authorized and must originate from within the merchant decryption environment.
4A-1.5.a Examine documented policies and procedures, and interview responsible personnel to verify that logical administrative/privileged access to the systems within the decryption environment must be authorized and originate from within the merchant decryption environment.
Documented policies and procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 4A-1.5.b Examine firewall/router configurations to verify that logical administrative/privileged access to systems within the decryption environment is authorized and originates from within the merchant decryption environment.
Describe how firewall/router configurations verified that logical administrative/privileged access to systems within the decryption environment is authorized and originates from within the merchant decryption environment:
<Report …
<Report Findings Here> 4A-1.5 Logical administrative/privileged access to systems within the decryption environment must be authorized and must originate from within the merchant decryption environment.
4A-1.5.a Examine documented policies and procedures, and interview responsible personnel to verify that logical administrative/privileged access to the systems within the decryption environment must be authorized and originate from within the merchant decryption environment.
Documented policies and procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 4A-1.5.b Examine firewall/router configurations to verify that logical administrative/privileged access to systems within the decryption environment is authorized and originates from within the merchant decryption environment.
Describe how firewall/router configurations verified that logical administrative/privileged access to systems within the decryption environment is authorized and originates from within the merchant decryption environment:
<Report …
Added
p. 58
Firewalls must be configured to restrict traffic as follows:
4A-2.1 Review documentation and observe network configurations to verify that firewalls are in place between the merchant decryption environment and all other networks.
Documentation reviewed: <Report Findings Here> Describe how network configurations verified that firewalls are in place between the merchant decryption environment and all other networks:
<Report Findings Here> 4A-2.1.1 Inbound and outbound traffic to/from the decryption environment must be restricted to only IP addresses within the CDE.
4A-2.1.1 Examine firewall and router configurations to verify that inbound and outbound traffic to/from the decryption environment is limited to only IP addresses within the CDE.
Describe how firewall and router configurations verified that inbound and outbound traffic to/from the decryption environment is limited to only IP addresses within the CDE:
<Report Findings Here> 4A-2.1.2 Inbound and outbound traffic between the decryption environment and any CDE must be restricted to only that which is necessary for performing and/or …
4A-2.1 Review documentation and observe network configurations to verify that firewalls are in place between the merchant decryption environment and all other networks.
Documentation reviewed: <Report Findings Here> Describe how network configurations verified that firewalls are in place between the merchant decryption environment and all other networks:
<Report Findings Here> 4A-2.1.1 Inbound and outbound traffic to/from the decryption environment must be restricted to only IP addresses within the CDE.
4A-2.1.1 Examine firewall and router configurations to verify that inbound and outbound traffic to/from the decryption environment is limited to only IP addresses within the CDE.
Describe how firewall and router configurations verified that inbound and outbound traffic to/from the decryption environment is limited to only IP addresses within the CDE:
<Report Findings Here> 4A-2.1.2 Inbound and outbound traffic between the decryption environment and any CDE must be restricted to only that which is necessary for performing and/or …
Added
p. 59
Wireless connections to the decryption environment are prohibited.
Processes are implemented to detect and immediately (as soon as possible) respond to physical connections (e.g., wireless connections) to the decryption environment.
4A-2.3.a Review document policies and procedures to verify that wireless connections to the decryption environment are prohibited. Documented policies and procedures reviewed: <Report Findings Here> 4A-2.3.b Observe processes and interview personnel to verify a methodology is implemented to immediately (e.g., ASAP) detect, identify, and eliminate any unauthorized physical connections (e.g., wireless access points) that connect to the decryption environment.
Personnel interviewed: <Report Findings Here> Describe how observed processes verified that a methodology is implemented to immediately detect, identify, and eliminate any unauthorized physical connections that connect to the decryption environment:
<Report Findings Here> 4A-2.3.c Examine firewall/router configurations to confirm that all wireless networks are prevented from connecting to the decryption environment. Describe how firewall/router configurations confirmed that all wireless networks are prevented …
Processes are implemented to detect and immediately (as soon as possible) respond to physical connections (e.g., wireless connections) to the decryption environment.
4A-2.3.a Review document policies and procedures to verify that wireless connections to the decryption environment are prohibited. Documented policies and procedures reviewed: <Report Findings Here> 4A-2.3.b Observe processes and interview personnel to verify a methodology is implemented to immediately (e.g., ASAP) detect, identify, and eliminate any unauthorized physical connections (e.g., wireless access points) that connect to the decryption environment.
Personnel interviewed: <Report Findings Here> Describe how observed processes verified that a methodology is implemented to immediately detect, identify, and eliminate any unauthorized physical connections that connect to the decryption environment:
<Report Findings Here> 4A-2.3.c Examine firewall/router configurations to confirm that all wireless networks are prevented from connecting to the decryption environment. Describe how firewall/router configurations confirmed that all wireless networks are prevented …
Added
p. 60
<Report Findings Here> 4B-1.1.c Observe traffic between the encryption environment and any other CDE to verify the traffic is limited to systems directly related to supporting P2PE transactions, transaction processing, and/or terminal-management functions.
Describe how the observed traffic between the encryption environment and any other CDE verified that the traffic is limited to systems directly related to supporting P2PE transactions, transaction processing, and/or terminal- management functions:
<Report Findings Here> 4B-1.2 Processes must be implemented to prevent clear-text account data from being transmitted from the CDE back to the encryption environment.
4B-1.2.a Review documented policies and procedures for the CDE to verify that the transmission of clear-text account data from the CDE back to the encryption environment is prohibited.
Documented policies and procedures for the CDE. reviewed: <Report Findings Here> 4B-1.2.b Observe processes and interview personnel to verify clear-text account data is prevented from being transmitted from the CDE back to the encryption environment.
Personnel interviewed: …
Describe how the observed traffic between the encryption environment and any other CDE verified that the traffic is limited to systems directly related to supporting P2PE transactions, transaction processing, and/or terminal- management functions:
<Report Findings Here> 4B-1.2 Processes must be implemented to prevent clear-text account data from being transmitted from the CDE back to the encryption environment.
4B-1.2.a Review documented policies and procedures for the CDE to verify that the transmission of clear-text account data from the CDE back to the encryption environment is prohibited.
Documented policies and procedures for the CDE. reviewed: <Report Findings Here> 4B-1.2.b Observe processes and interview personnel to verify clear-text account data is prevented from being transmitted from the CDE back to the encryption environment.
Personnel interviewed: …
Added
p. 61
Sample of system components in the CDE: <Report Findings Here> Sample of system components in the decryption environment: <Report Findings Here> Describe how system configurations and access control lists verified that encryption environment personnel do not have access to any system components in the decryption environment or the CDE:
Added
p. 62
5A-1 Use approved decryption devices 5B Secure the decryption environment.
5B-1 Maintain processes for securely managing the decryption environment.
5C Monitor the decryption environment and respond to incidents.
5C-1 Perform logging and monitor the decryption environment for suspicious activity, and implement notification processes.
5D Implement secure, hybrid decryption processes.
5D-1 Configure the Host System securely.
5D-2 Access controls for the Host System are configured securely.
5D-3 Non-console access to the Host System is configured securely.
5D-4 The physical environment of the Host System is secured.
5E Component providers ONLY: report status to solution providers.
5E-1 For component providers of decryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
5B-1 Maintain processes for securely managing the decryption environment.
5C Monitor the decryption environment and respond to incidents.
5C-1 Perform logging and monitor the decryption environment for suspicious activity, and implement notification processes.
5D Implement secure, hybrid decryption processes.
5D-1 Configure the Host System securely.
5D-2 Access controls for the Host System are configured securely.
5D-3 Non-console access to the Host System is configured securely.
5D-4 The physical environment of the Host System is secured.
5E Component providers ONLY: report status to solution providers.
5E-1 For component providers of decryption-management services, maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
Added
p. 63
FIPS140-2 Level 3 (overall) or higher certified, or PCI PTS HSM approved.
5A-1.1.a For all HSMs used in the decryption environment, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs used in the solution are either:
Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 Level 3 (overall), or higher. Refer to http://csrc.nist.gov.
Listed on the PCI SSC website, with a valid PCI SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Approval documentation reviewed: <Report Findings Here> 5A-1.1.b Examine documented procedures and interview personnel to verify that all account-data decryption operations are performed only by the FIPS- approved and/or PTS-approved HSMs identified in 5A-1.1.a.
Vendor name Model name and number Hardware version number Device firmware version number …
5A-1.1.a For all HSMs used in the decryption environment, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs used in the solution are either:
Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 Level 3 (overall), or higher. Refer to http://csrc.nist.gov.
Listed on the PCI SSC website, with a valid PCI SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Approval documentation reviewed: <Report Findings Here> 5A-1.1.b Examine documented procedures and interview personnel to verify that all account-data decryption operations are performed only by the FIPS- approved and/or PTS-approved HSMs identified in 5A-1.1.a.
Vendor name Model name and number Hardware version number Device firmware version number …
Added
p. 64
Vendor name Model name/number Hardware version number Firmware version number For each FIPS-approved HSM used in the solution, describe how the HSM device configurations observed verified that all of the device characteristics at 5A-1.1.1.b match the FIPS140-2 Level 3 (or higher) approval listing:
<Report Findings Here> 5A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in an updated HSM firmware version, and the PCI SSC or NIST validation of that updated firmware version has not yet been completed, obtain the vendor documentation and verify it includes confirmation that the update has been submitted for evaluation per the process specified by PCI SSC or NIST (as applicable to the HSM).
Vendor documentation reviewed: <Report Findings Here> 5A-1.1.2 If FIPS-approved HSMs are used, the HSM must use the FIPS-approved cryptographic primitives, data-protection mechanisms, and key-management processes for account data decryption and related processes.
Note: Solution providers operating …
<Report Findings Here> 5A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in an updated HSM firmware version, and the PCI SSC or NIST validation of that updated firmware version has not yet been completed, obtain the vendor documentation and verify it includes confirmation that the update has been submitted for evaluation per the process specified by PCI SSC or NIST (as applicable to the HSM).
Vendor documentation reviewed: <Report Findings Here> 5A-1.1.2 If FIPS-approved HSMs are used, the HSM must use the FIPS-approved cryptographic primitives, data-protection mechanisms, and key-management processes for account data decryption and related processes.
Note: Solution providers operating …
Added
p. 65
Note: PCI HSMs require that the decryption-device manufacturer make available a security policy document to end users, providing information on how the device must be installed, maintained, and configured to meet the compliance requirements under which it was approved.
5A-1.1.3 Examine HSM configurations for all P2PE solution functions to verify that HSMs are configured to operate according to the security policy that was included as part of the PTS approval.
Describe how HSM configurations for all P2PE security functions verified that HSMs are configured to operate according to the security policy that was included as part of the PTS approval:
<Report Findings Here> 5B-1.1 Current documentation must be maintained that describes or illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
5B-1.1.a Interview responsible personnel and review documentation to verify that a …
5A-1.1.3 Examine HSM configurations for all P2PE solution functions to verify that HSMs are configured to operate according to the security policy that was included as part of the PTS approval.
Describe how HSM configurations for all P2PE security functions verified that HSMs are configured to operate according to the security policy that was included as part of the PTS approval:
<Report Findings Here> 5B-1.1 Current documentation must be maintained that describes or illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
5B-1.1.a Interview responsible personnel and review documentation to verify that a …
Added
p. 66
Assigning administrative roles and responsibilities only to specific, authorized personnel Management of user interface Password/smart card management Console/remote administration Access to physical keys Use of HSM commands Documented procedures reviewed: <Report Findings Here> 5B-1.2.b Observe authorized personnel performing device-administration operations to verify secure administration procedures are implemented for the following:
Management of user interface Password/smart card management Console/remote administration Access to physical keys Use of HSM commands Describe how the observation verified that secure administration procedures are implemented for the following:
Management of user interface Password/smart card management Console/remote administration Access to physical keys Use of HSM commands <Report Findings Here> 5B-1.2.c Observe personnel performing decryption-device administration and examine files/records that assign administrative roles and responsibilities to verify that only authorized and assigned personnel perform decryption-device administration operations.
Files/records examined: <Report Findings Here> Describe how the observation …
Management of user interface Password/smart card management Console/remote administration Access to physical keys Use of HSM commands Describe how the observation verified that secure administration procedures are implemented for the following:
Management of user interface Password/smart card management Console/remote administration Access to physical keys Use of HSM commands <Report Findings Here> 5B-1.2.c Observe personnel performing decryption-device administration and examine files/records that assign administrative roles and responsibilities to verify that only authorized and assigned personnel perform decryption-device administration operations.
Files/records examined: <Report Findings Here> Describe how the observation …
Added
p. 67
Note: This authentication can occur via use of cryptographic keys or certificates, uniquely associated with each POI device and decryption system.
5B-1.4.a Examine documented policies and procedures to verify they require POI devices be authenticated upon connection to the decryption environment and upon request by the solution provider.
Procedures and/or mechanisms for authenticating POI devices upon connection to the decryption environment Procedures and/or mechanisms for authenticating POI devices upon request by the solution provider Documented policies and procedures reviewed: <Report Findings Here> 5B-1.4.c Interview responsible personnel and observe a sample of device authentications to verify the following:
POI devices are authenticated upon connection to the decryption environment.
POI devices are authenticated upon request by the solution provider.
Responsible personnel interviewed: <Report Findings Here> Describe how sample device authentications verified that POI devices are authenticated upon connection to the decryption environment and upon request by the solution provider:
<Report Findings Here> 5B-1.5 Physical …
5B-1.4.a Examine documented policies and procedures to verify they require POI devices be authenticated upon connection to the decryption environment and upon request by the solution provider.
Procedures and/or mechanisms for authenticating POI devices upon connection to the decryption environment Procedures and/or mechanisms for authenticating POI devices upon request by the solution provider Documented policies and procedures reviewed: <Report Findings Here> 5B-1.4.c Interview responsible personnel and observe a sample of device authentications to verify the following:
POI devices are authenticated upon connection to the decryption environment.
POI devices are authenticated upon request by the solution provider.
Responsible personnel interviewed: <Report Findings Here> Describe how sample device authentications verified that POI devices are authenticated upon connection to the decryption environment and upon request by the solution provider:
<Report Findings Here> 5B-1.5 Physical …
Added
p. 68
Note: For merchant-managed solutions, PCI DSS validation of the decryption environment is managed by the merchant in accordance with their acquirer and/or payment brand. This requirement is therefore not applicable to P2PE assessments where merchants are the P2PE solution provider.
Note: The QSA (P2PE) should NOT challenge or re-evaluate the PCI DSS environment (or its compliance) where a completed and current ROC exists.
5B-1.6.a Review the “Description of Scope of Work and Approach Taken”
section of the solution provider’s current PCI DSS Report on Compliance (ROC) to verify the PCI DSS assessment scope fully covers the P2PE decryption environment.
PCI DSS Report on Compliance (ROC) reviewed: <Report Findings Here> 5B-1.6.b Review PCI DSS ROC and/or Attestation of Compliance (AOC) to verify that all applicable PCI DSS requirements are “in place” for the P2PE decryption environment.
PCI DSS Report on Compliance (ROC) and/or Attestation of Compliance (AOC) reviewed:
PCI DSS Report on Compliance (ROC) and/or Attestation of …
Note: The QSA (P2PE) should NOT challenge or re-evaluate the PCI DSS environment (or its compliance) where a completed and current ROC exists.
5B-1.6.a Review the “Description of Scope of Work and Approach Taken”
section of the solution provider’s current PCI DSS Report on Compliance (ROC) to verify the PCI DSS assessment scope fully covers the P2PE decryption environment.
PCI DSS Report on Compliance (ROC) reviewed: <Report Findings Here> 5B-1.6.b Review PCI DSS ROC and/or Attestation of Compliance (AOC) to verify that all applicable PCI DSS requirements are “in place” for the P2PE decryption environment.
PCI DSS Report on Compliance (ROC) and/or Attestation of Compliance (AOC) reviewed:
PCI DSS Report on Compliance (ROC) and/or Attestation of …
Added
p. 69
Describe how process flows and data flows verified that there is no process, application, or other mechanism that sends more digits of truncated PANs back to the encryption environment than is specified in PCI DSS and/or related <Report Findings Here> 5B-1.9 Any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must ensure that the ONLY allowed output of clear-text account data is for non-PCI payment brand account/card data, and includes the following:
Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
Approval of functionality by authorized personnel prior to implementation Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that …
Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
Cryptographic signing (or similar) prior to installation by authorized personnel using dual control.
Approval of functionality by authorized personnel prior to implementation Documentation for all new installations or updates to whitelist functionality that includes the following: o Description and justification for the functionality o Who approved the new installation or updated functionality prior to release o Confirmation that …
Added
p. 70
Personnel interviewed <Report Findings Here> Describe how application and system configurations observed verified that whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows the output of clear-text account data for non-PCI payment brand account/card data:
<Report Findings Here> 5B-1.9.1.b Perform test transactions to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output clear-text account for non-PCI payment brand account/card data.
Describe how test transactions verified that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output clear-text account for non-PCI payment brand account/card data:
<Report Findings Here> 5B-1.9.2 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must be:
Cryptographically signed (or similar) prior to installation only by authorized personnel using dual control Cryptographically …
<Report Findings Here> 5B-1.9.1.b Perform test transactions to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output clear-text account for non-PCI payment brand account/card data.
Describe how test transactions verified that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output clear-text account for non-PCI payment brand account/card data:
<Report Findings Here> 5B-1.9.2 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must be:
Cryptographically signed (or similar) prior to installation only by authorized personnel using dual control Cryptographically …
Added
p. 71
The documentation includes description and justification.
The documentation includes confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Records of updated whitelisting functionality reviewed: <Report Findings Here> 5C-1.1 Changes to the critical functions of the decryption devices must be logged.
Note: Critical functions include but are not limited to application and firmware updates, key-injection, as well as changes to security-sensitive configurations.
5C-1.1 Examine system configurations and correlating log files to verify that any changes to the critical functions of decryption devices are logged, including:
Changes to the applications Changes to the firmware Changes to any security-sensitive configurations Describe how system configurations and correlating log files verified that any changes to the critical functions of decryption devices are logged, including:
Changes to the applications Changes to the firmware Changes to any security-sensitive configurations <Report Findings Here> 5C-1.2 Mechanisms must be implemented to detect …
The documentation includes confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Records of updated whitelisting functionality reviewed: <Report Findings Here> 5C-1.1 Changes to the critical functions of the decryption devices must be logged.
Note: Critical functions include but are not limited to application and firmware updates, key-injection, as well as changes to security-sensitive configurations.
5C-1.1 Examine system configurations and correlating log files to verify that any changes to the critical functions of decryption devices are logged, including:
Changes to the applications Changes to the firmware Changes to any security-sensitive configurations Describe how system configurations and correlating log files verified that any changes to the critical functions of decryption devices are logged, including:
Changes to the applications Changes to the firmware Changes to any security-sensitive configurations <Report Findings Here> 5C-1.2 Mechanisms must be implemented to detect …
Added
p. 72
Physical breach Tampered, missing, or substituted devices Unauthorized logical alterations (e.g., configurations, access controls) Unauthorized use of sensitive functions (e.g., key-management functions) Disconnect/reconnect of devices Failure of any device security control Encryption/decryption failures Unauthorized use of the HSM API Documented procedures reviewed: <Report Findings Here> 5C-1.2.b Interview personnel and observe implemented mechanisms to verify mechanisms are implemented to detect and respond to suspicious activity, including:
Physical breach Tampered, missing, or substituted devices Unauthorized logical alterations (configuration, access controls) Unauthorized use of sensitive functions (e.g., key management functions) Disconnect/reconnect of devices Failure of any device security control Encryption/decryption failures Unauthorized use of the HSM API Personnel interviewed: <Report Findings Here> Describe the implemented mechanisms that were observed to be implemented to detect and respond to suspicious activity:
<Report Findings Here> 5C-1.3 Mechanisms must be implemented to detect …
Physical breach Tampered, missing, or substituted devices Unauthorized logical alterations (configuration, access controls) Unauthorized use of sensitive functions (e.g., key management functions) Disconnect/reconnect of devices Failure of any device security control Encryption/decryption failures Unauthorized use of the HSM API Personnel interviewed: <Report Findings Here> Describe the implemented mechanisms that were observed to be implemented to detect and respond to suspicious activity:
<Report Findings Here> 5C-1.3 Mechanisms must be implemented to detect …
Added
p. 73
Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification upon detection of incoming clear-text account data:
<Report Findings Here> 5C-1.3.1.c Interview personnel to verify that designated personnel are immediately notified upon detection of incoming clear-text account data. Personnel interviewed: <Report Findings Here> 5C-1.3.2 Detecting and reviewing any cryptographic errors reported by the HSM 5C-1.3.2.a Observe implemented processes to verify controls are in place to detect and review any cryptographic errors reported by the HSM. Describe how the implemented processes observed verified that controls are in place to detect and review and cryptographic errors reported by the HSM:
<Report Findings Here> 5C-1.3.2.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification of cryptographic errors reported by the HSM.
Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification of cryptographic errors reported by <Report Findings Here> 5C-1.3.2.c Interview personnel …
<Report Findings Here> 5C-1.3.1.c Interview personnel to verify that designated personnel are immediately notified upon detection of incoming clear-text account data. Personnel interviewed: <Report Findings Here> 5C-1.3.2 Detecting and reviewing any cryptographic errors reported by the HSM 5C-1.3.2.a Observe implemented processes to verify controls are in place to detect and review any cryptographic errors reported by the HSM. Describe how the implemented processes observed verified that controls are in place to detect and review and cryptographic errors reported by the HSM:
<Report Findings Here> 5C-1.3.2.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification of cryptographic errors reported by the HSM.
Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification of cryptographic errors reported by <Report Findings Here> 5C-1.3.2.c Interview personnel …
Added
p. 74
Describe how the implemented processes observed verified that controls are in place to review data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections:
<Report Findings Here> 5C-1.3.4.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections:
<Report Findings Here> 5C-1.3.4.c Interview personnel to verify that designated personnel are immediately notified upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
Personnel interviewed: <Report Findings Here> 5C-1.4 All suspicious activity must be identified and a record maintained, to include at least the following:
Identification of affected device(s), including make, …
<Report Findings Here> 5C-1.3.4.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
Describe the implemented controls and notification mechanisms observed that detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections:
<Report Findings Here> 5C-1.3.4.c Interview personnel to verify that designated personnel are immediately notified upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
Personnel interviewed: <Report Findings Here> 5C-1.4 All suspicious activity must be identified and a record maintained, to include at least the following:
Identification of affected device(s), including make, …
Added
p. 75
Identification of affected device(s), including make, model, and serial Identification of affected merchant, including specific sites/locations if applicable Date/time of incident Duration of device downtime Date/time the issue was resolved Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled Describe how the implemented controls verified that the source of any suspicious activity is identified, and records are maintained to include the following:
Identification of affected device(s), including make, model, and serial Identification of affected merchant, including specific sites/locations if applicable Date/time of incident Duration of device downtime Date/time the issue was resolved Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled <Report Findings Here> 5C-1.5 Implement mechanisms to provide immediate notification of suspicious activity to …
Identification of affected device(s), including make, model, and serial Identification of affected merchant, including specific sites/locations if applicable Date/time of incident Duration of device downtime Date/time the issue was resolved Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled <Report Findings Here> 5C-1.5 Implement mechanisms to provide immediate notification of suspicious activity to …
Added
p. 76
Solution provider documentation reviewed: <Report Findings Here> 5D-1.2 The Host System must be isolated, or dedicated, to transaction processing, with only necessary services, protocols, daemons etc. enabled:
The necessary services, protocols, daemons etc. must be documented and justified, including description of the enabled security features for these services etc.
Functions not related to transaction processing must be disabled, or isolated (e.g., using logical partitions), from transaction processing.
Note: “Isolated” means that the Host System must not be accessed, modified or intercepted by other processes.
5D-1.2.a Inspect network and system configuration settings to verify the host processing system is isolated, or dedicated, to transaction processing, with only necessary services, protocols, daemons etc. enabled.
Describe how network and system configuration settings verified that the host processing system is isolated, or dedicated, to transaction processing, with only necessary services, protocols, daemons etc. enabled:
<Report Findings Here> 5D-1.2.b Review the documented record of services, protocols, daemons etc. that …
The necessary services, protocols, daemons etc. must be documented and justified, including description of the enabled security features for these services etc.
Functions not related to transaction processing must be disabled, or isolated (e.g., using logical partitions), from transaction processing.
Note: “Isolated” means that the Host System must not be accessed, modified or intercepted by other processes.
5D-1.2.a Inspect network and system configuration settings to verify the host processing system is isolated, or dedicated, to transaction processing, with only necessary services, protocols, daemons etc. enabled.
Describe how network and system configuration settings verified that the host processing system is isolated, or dedicated, to transaction processing, with only necessary services, protocols, daemons etc. enabled:
<Report Findings Here> 5D-1.2.b Review the documented record of services, protocols, daemons etc. that …
Added
p. 77
<Report Findings Here> 5D-1.5 A process, either automated or manual, must be in place to prevent and/or detect and alert, any unauthorized changes to applications/software on the Host System.
5D-1.5.a Examine documented policies and procedures to verify that a process is defined to prevent and/or detect and alert, any unauthorized changes to applications/software.
Documented policies and procedures reviewed: <Report Findings Here> 5D-1.5.b Interview personnel and observe system configurations to verify that controls are implemented to prevent and/or detect and alert personnel, upon any unauthorized changes to applications/software.
Personnel interviewed: <Report Findings Here> Describe how the system configurations observed verified that controls are implemented to prevent and/or detect and alert personnel, upon any unauthorized changes to applications/software:
<Report Findings Here> 5D-1.5.c Examine output from the implemented process to verify that any unauthorized changes to applications/software are either prevented or detected with an alert generated that is immediately investigated.
Describe how the output from the implemented process …
5D-1.5.a Examine documented policies and procedures to verify that a process is defined to prevent and/or detect and alert, any unauthorized changes to applications/software.
Documented policies and procedures reviewed: <Report Findings Here> 5D-1.5.b Interview personnel and observe system configurations to verify that controls are implemented to prevent and/or detect and alert personnel, upon any unauthorized changes to applications/software.
Personnel interviewed: <Report Findings Here> Describe how the system configurations observed verified that controls are implemented to prevent and/or detect and alert personnel, upon any unauthorized changes to applications/software:
<Report Findings Here> 5D-1.5.c Examine output from the implemented process to verify that any unauthorized changes to applications/software are either prevented or detected with an alert generated that is immediately investigated.
Describe how the output from the implemented process …
Added
p. 77
Testing integrity of firmware.
Added
p. 77
5D-1.6.a Inspect Host System configuration settings, and examine vendor/solution provider documentation to verify that the Host System performs a self-test when it is powered up to ensure its integrity before use. Verify the self-test includes the following:
Testing integrity of software/firmware.
Testing integrity of software/firmware.
Vendor/solution provider documentation reviewed: <Report Findings Here> Describe how Host System configuration settings and vendor/solution provider documentation verified that the Host System performs a self-test when it is powered up to ensure its integrity before use, and that the self-test includes the following:
<Report Findings Here> Personnel interviewed: <Report Findings Here>
Testing integrity of software/firmware.
Testing integrity of software/firmware.
Vendor/solution provider documentation reviewed: <Report Findings Here> Describe how Host System configuration settings and vendor/solution provider documentation verified that the Host System performs a self-test when it is powered up to ensure its integrity before use, and that the self-test includes the following:
<Report Findings Here> Personnel interviewed: <Report Findings Here>
Added
p. 78
Describe how logs/audit trails verified that the Host System performs a self-test to ensure its integrity before use and that the self-tests included the tests described in 5D-1.6.a:
<Report Findings Here> 5D-1.7 The Host System must perform a self-test when a security-impacting function or operation is modified (e.g., an integrity check of the software/firmware must be performed upon loading of a software/firmware update).
5D-1.7.a Inspect Host System configuration settings and examine vendor/solution provider documentation to verify that the Host system performs a self-test when a security-impacting function or operation is modified.
Vendor/solution provider documentation reviewed: <Report Findings Here> Describe how Host System configuration settings and vendor/solution provider documentation verified that the Host system performs a self-test when a security-impacting function or operation is modified:
<Report Findings Here> 5D-1.7.b Interview personnel and examine logs/records for when a security- impacting function, or operation, has been modified to verify that the Host System performs a self-test.
Personnel interviewed: …
<Report Findings Here> 5D-1.7 The Host System must perform a self-test when a security-impacting function or operation is modified (e.g., an integrity check of the software/firmware must be performed upon loading of a software/firmware update).
5D-1.7.a Inspect Host System configuration settings and examine vendor/solution provider documentation to verify that the Host system performs a self-test when a security-impacting function or operation is modified.
Vendor/solution provider documentation reviewed: <Report Findings Here> Describe how Host System configuration settings and vendor/solution provider documentation verified that the Host system performs a self-test when a security-impacting function or operation is modified:
<Report Findings Here> 5D-1.7.b Interview personnel and examine logs/records for when a security- impacting function, or operation, has been modified to verify that the Host System performs a self-test.
Personnel interviewed: …
Added
p. 79
Failure of a cryptographic operation Failure of a system self-test, as described in Requirements 5D-1.6 and 5D- Failure of a security function or mechanism Logs/records of actual or test alerts examined: <Report Findings Here> 5D-1.9 Alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
5D-1.9.a Review documented procedures to verify alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
Documented procedures reviewed: <Report Findings Here> 5D-1.9.b Examine system configurations and records of documented alert events to verify alerts generated from the Host System are documented. Records of documented alert events reviewed: <Report Findings Here> Describe how system configurations and records of documented alert events verified that alerts generated from the Host System are documented:
<Report Findings Here> 5D-1.9.c Examine a sample of documented alert events and …
5D-1.9.a Review documented procedures to verify alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
Documented procedures reviewed: <Report Findings Here> 5D-1.9.b Examine system configurations and records of documented alert events to verify alerts generated from the Host System are documented. Records of documented alert events reviewed: <Report Findings Here> Describe how system configurations and records of documented alert events verified that alerts generated from the Host System are documented:
<Report Findings Here> 5D-1.9.c Examine a sample of documented alert events and …
Added
p. 79
During diagnostics of cryptographic operations.
During diagnostics of cryptographic operations.
During diagnostics of cryptographic operations.
Added
p. 80
Describe how Host System configuration settings verified that controls and/or procedures are in place to ensure that the Host System does not perform any cryptographic operations:
During diagnostics of cryptographic operations <Report Findings Here> 5D-1.11 All source code and executable code for cryptographic software and firmware on the Host System must be protected from unauthorized disclosure and unauthorized modification.
5D-1.11.a Inspect configuration documentation to verify that access controls are defined to ensure all source code and executable code for cryptographic software and firmware is protected from unauthorized disclosure and unauthorized modification.
Configuration documentation inspected: <Report Findings Here> 5D-1.11.b Observe access controls for cryptographic software and firmware to verify that all source code and executable code is protected from unauthorized disclosure and unauthorized modification.
Describe how the access controls for cryptographic software and firmware observed verified that all source code and executable code is protected from unauthorized disclosure and unauthorized modification:
<Report Findings Here> 5D-1.12 …
During diagnostics of cryptographic operations <Report Findings Here> 5D-1.11 All source code and executable code for cryptographic software and firmware on the Host System must be protected from unauthorized disclosure and unauthorized modification.
5D-1.11.a Inspect configuration documentation to verify that access controls are defined to ensure all source code and executable code for cryptographic software and firmware is protected from unauthorized disclosure and unauthorized modification.
Configuration documentation inspected: <Report Findings Here> 5D-1.11.b Observe access controls for cryptographic software and firmware to verify that all source code and executable code is protected from unauthorized disclosure and unauthorized modification.
Describe how the access controls for cryptographic software and firmware observed verified that all source code and executable code is protected from unauthorized disclosure and unauthorized modification:
<Report Findings Here> 5D-1.12 …
Added
p. 81
‘Core dumps’ of memory required for troubleshooting.
In the above circumstances, the following conditions apply:
5D-1.14.a Examine documented configuration procedures to verify that the Host System must not write clear-text cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
Core dumps’ of memory required for trouble-shooting.
Documented configuration procedures reviewed: <Report Findings Here> 5D-1.14.b Examine Host System configuration settings and interview personnel to verify that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:
‘Core dumps’ of memory required for trouble-shooting.
‘Core dumps’ of memory required for trouble-shooting.
Personnel interviewed: <Report Findings Here> Describe how the Host System configuration settings examined verified that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:
<Report Findings Here> 5D-1.14.c Verify documented procedures include Requirements 5D-1.14.1 through 5D-1.14.5 below.
5D-1.14.1 The locations must be predefined and documented.
5D-1.14.1.a Review Host System configuration …
In the above circumstances, the following conditions apply:
5D-1.14.a Examine documented configuration procedures to verify that the Host System must not write clear-text cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
Core dumps’ of memory required for trouble-shooting.
Documented configuration procedures reviewed: <Report Findings Here> 5D-1.14.b Examine Host System configuration settings and interview personnel to verify that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:
‘Core dumps’ of memory required for trouble-shooting.
‘Core dumps’ of memory required for trouble-shooting.
Personnel interviewed: <Report Findings Here> Describe how the Host System configuration settings examined verified that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:
<Report Findings Here> 5D-1.14.c Verify documented procedures include Requirements 5D-1.14.1 through 5D-1.14.5 below.
5D-1.14.1 The locations must be predefined and documented.
5D-1.14.1.a Review Host System configuration …
Added
p. 82
Describe how the backup configuration settings for the Host System and storage locations examined verified that ‘swap/page’ files and ‘core dumps’ are not backed up:
<Report Findings Here> 5D-1.14.3.b Examine configurations of storage locations to verify that ‘swap/page’ files and ‘core dumps’ cannot be copied off the storage locations. Describe how the configurations of storage locations examined verified that ‘swap/page’ files and ‘core dumps’ cannot be copied off the storage locations:
<Report Findings Here> 5D-1.14.4 Access to, and the use of, any tools used for trouble-shooting or forensics must be strictly controlled.
5D-1.14.4.a Examine documented procedures to verify that controls are defined to ensure that the access to, and use of, any tools used for trouble-shooting or forensics, are strictly controlled.
Documented procedures reviewed: <Report Findings Here> 5D-1.14.4.b Observe the process for accessing the tools used for trouble- shooting or forensics, and verify that they are strictly controlled in accordance with the documented procedure.
Describe …
<Report Findings Here> 5D-1.14.3.b Examine configurations of storage locations to verify that ‘swap/page’ files and ‘core dumps’ cannot be copied off the storage locations. Describe how the configurations of storage locations examined verified that ‘swap/page’ files and ‘core dumps’ cannot be copied off the storage locations:
<Report Findings Here> 5D-1.14.4 Access to, and the use of, any tools used for trouble-shooting or forensics must be strictly controlled.
5D-1.14.4.a Examine documented procedures to verify that controls are defined to ensure that the access to, and use of, any tools used for trouble-shooting or forensics, are strictly controlled.
Documented procedures reviewed: <Report Findings Here> 5D-1.14.4.b Observe the process for accessing the tools used for trouble- shooting or forensics, and verify that they are strictly controlled in accordance with the documented procedure.
Describe …
Added
p. 83
Note: This requirement applies to all user roles associated to persons with access to the Host System.
5D-2.1.a Examine documented policies and procedures to verify that the Host System (s) user passwords must be changed at least every 30 days. Documented policies and procedures reviewed: <Report Findings Here> 5D-2.1.b Inspect Host System configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days.
Describe how the Host System configuration settings inspected verified that user password parameters are set to require users to change passwords at least every 30 days:
<Report Findings Here> 5D-2.2 User passwords must meet the following:
5D-2.1.a Examine documented policies and procedures to verify that the Host System (s) user passwords must be changed at least every 30 days. Documented policies and procedures reviewed: <Report Findings Here> 5D-2.1.b Inspect Host System configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days.
Describe how the Host System configuration settings inspected verified that user password parameters are set to require users to change passwords at least every 30 days:
<Report Findings Here> 5D-2.2 User passwords must meet the following:
Added
p. 83
5D-2.2.a Examine documented policies and procedures to verify that user passwords must:
Documented policies and procedures reviewed: <Report Findings Here> 5D-2.2.b Inspect Host System (s) configuration settings to verify that user passwords:
Describe how the Host System configuration settings inspected verified that user passwords:
<Report Findings Here> 5D-2.3 Where log-on security tokens (e.g., smart cards) are used to access the Host System, the security tokens must have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage. The PIN or password/passphrase must be at least ten alphanumeric characters in length, or equivalent.
5D-2.3.a If log-on security tokens are used, observe the security tokens in use to verify that they have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage.
Log-on security tokens in use: <Report Findings Here> Describe how log-on security tokens in use verified that an associated usage- authentication …
Documented policies and procedures reviewed: <Report Findings Here> 5D-2.2.b Inspect Host System (s) configuration settings to verify that user passwords:
Describe how the Host System configuration settings inspected verified that user passwords:
<Report Findings Here> 5D-2.3 Where log-on security tokens (e.g., smart cards) are used to access the Host System, the security tokens must have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage. The PIN or password/passphrase must be at least ten alphanumeric characters in length, or equivalent.
5D-2.3.a If log-on security tokens are used, observe the security tokens in use to verify that they have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage.
Log-on security tokens in use: <Report Findings Here> Describe how log-on security tokens in use verified that an associated usage- authentication …
Added
p. 84
5D-2.4.a Examine documented policies and procedures to verify that authentication parameters on the Host System must be set to require that a user’s account be locked out after not more than five invalid logon attempts.
Documented policies and procedures reviewed: <Report Findings Here> 5D-2.4.b Inspect Host System configuration settings to verify that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts.
Describe how the Host System configuration settings inspected verified that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts:
<Report Findings Here> 5D-2.5 The Host System must enforce role-based access control to include, at a minimum, the following roles:
Documented policies and procedures reviewed: <Report Findings Here> 5D-2.4.b Inspect Host System configuration settings to verify that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts.
Describe how the Host System configuration settings inspected verified that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts:
<Report Findings Here> 5D-2.5 The Host System must enforce role-based access control to include, at a minimum, the following roles:
Added
p. 84
Cryptographic administrator role
• configuration of cryptographic management functions Host System security role
• auditing of host functions 5D-2.5.a Examine documented access-control procedures to verify they define, as a minimum, the following roles:
Cryptographic administrator role
• configuration of cryptographic management functions Host System security role
• auditing of host functions Documented access-control procedures reviewed: <Report Findings Here> 5D-2.5.b Inspect the Host System configuration settings to verify that role- based access control is enforced and, at a minimum, the following roles are Host System operator role
• for day-to-day non-sensitive operations of the Host System.
Cryptographic administrator role
• configuration of cryptographic management functions Host System security role
• auditing of host functions.
Cryptographic administrator role
• configuration of cryptographic management functions Host System security role
• auditing of host functions.
Describe how the Host System configuration settings inspected verified that role-based access control is enforced and, at a minimum, the following roles are …
• configuration of cryptographic management functions Host System security role
• auditing of host functions 5D-2.5.a Examine documented access-control procedures to verify they define, as a minimum, the following roles:
Cryptographic administrator role
• configuration of cryptographic management functions Host System security role
• auditing of host functions Documented access-control procedures reviewed: <Report Findings Here> 5D-2.5.b Inspect the Host System configuration settings to verify that role- based access control is enforced and, at a minimum, the following roles are Host System operator role
• for day-to-day non-sensitive operations of the Host System.
Cryptographic administrator role
• configuration of cryptographic management functions Host System security role
• auditing of host functions.
Cryptographic administrator role
• configuration of cryptographic management functions Host System security role
• auditing of host functions.
Describe how the Host System configuration settings inspected verified that role-based access control is enforced and, at a minimum, the following roles are …
Added
p. 85
The following conditions must be applied:
5D-2.6.1 A Host System user must not be permitted to audit their own activity on the Host System.
5D-2.6.1.a Examine documented procedures to verify that a Host System user is not permitted to audit their own activity on the Host System. Documented procedures reviewed: <Report Findings Here> 5D-2.6.1.b Interview audit personnel to verify that a Host System user is not permitted to audit their own activity on the Host System. Audit personnel interviewed: <Report Findings Here> 5D-2.6.2 A Host System administrator must use their operator-level account when performing non-administrative functions.
5D-2.6.2.a Review documented policies and procedures to verify a Host System administrator is not permitted to use their administrative-level account when performing non-administrative functions.
Documented policies and procedures reviewed: <Report Findings Here> 5D-2.6.2.b Interview and observe a Host System administrator to verify they use their operator-level account when performing non-administrative functions. Host System administrator interviewed: <Report Findings Here> …
5D-2.6.1 A Host System user must not be permitted to audit their own activity on the Host System.
5D-2.6.1.a Examine documented procedures to verify that a Host System user is not permitted to audit their own activity on the Host System. Documented procedures reviewed: <Report Findings Here> 5D-2.6.1.b Interview audit personnel to verify that a Host System user is not permitted to audit their own activity on the Host System. Audit personnel interviewed: <Report Findings Here> 5D-2.6.2 A Host System administrator must use their operator-level account when performing non-administrative functions.
5D-2.6.2.a Review documented policies and procedures to verify a Host System administrator is not permitted to use their administrative-level account when performing non-administrative functions.
Documented policies and procedures reviewed: <Report Findings Here> 5D-2.6.2.b Interview and observe a Host System administrator to verify they use their operator-level account when performing non-administrative functions. Host System administrator interviewed: <Report Findings Here> …
Added
p. 85
5D-2.7.a Examine documented policies and procedures to verify that changes to a user’s access privileges are managed:
Documented policies and procedures reviewed: <Report Findings Here>
Documented policies and procedures reviewed: <Report Findings Here>
Added
p. 86
Describe how the observed process to change a user’s access privileges verified that it is managed:
<Report Findings Here> 5D-2.7.c Inspect the Host System configuration settings and, for a sample of user accounts, verify that any changes to their access privileges have been formally documented in the audit log.
Sample of user accounts: <Report Findings Here> Describe how the Host System configuration settings inspected verified that for the sample of user accounts, any changes to their access privileges have been formally documented in the audit log:
<Report Findings Here> 5D-2.8 All physical and logical access privileges must be reviewed at least quarterly to ensure that personnel with access to the decryption environment, the Host System and Host System software require that access for their position and job function.
5D-2.8.a Examine documented policies and procedures to verify that access privileges are reviewed, as a minimum, on a quarterly basis to ensure that the access privileges …
<Report Findings Here> 5D-2.7.c Inspect the Host System configuration settings and, for a sample of user accounts, verify that any changes to their access privileges have been formally documented in the audit log.
Sample of user accounts: <Report Findings Here> Describe how the Host System configuration settings inspected verified that for the sample of user accounts, any changes to their access privileges have been formally documented in the audit log:
<Report Findings Here> 5D-2.8 All physical and logical access privileges must be reviewed at least quarterly to ensure that personnel with access to the decryption environment, the Host System and Host System software require that access for their position and job function.
5D-2.8.a Examine documented policies and procedures to verify that access privileges are reviewed, as a minimum, on a quarterly basis to ensure that the access privileges …
Added
p. 87
<Report Findings Here> 5D-3.1.b Inspect the configuration settings of system components to verify that all traffic transmitted over the secure channel uses strong cryptography. Describe how the configuration settings of system components verified that all traffic transmitted over the secure channel uses strong cryptography:
<Report Findings Here> 5D-3.2 Non-console access to the Host System must not provide access to any other service, or channel, outside of that used to connect to the Host, e.g., “split tunneling.” 5D-3.2.a Inspect the configuration settings of the secure channel, to verify that ‘split tunneling’ is prohibited. Describe how the configuration settings of the secure channel verified that ‘split tunneling’ is prohibited:
<Report Findings Here> 5D-3.2.b Observe a Host System administrator log on to the device which provides non-console access to the Host System to verify that “split tunneling” is prohibited.
Describe how the Host System administrator’s log on to the device verified that ‘split tunneling’ is prohibited:
<Report …
<Report Findings Here> 5D-3.2 Non-console access to the Host System must not provide access to any other service, or channel, outside of that used to connect to the Host, e.g., “split tunneling.” 5D-3.2.a Inspect the configuration settings of the secure channel, to verify that ‘split tunneling’ is prohibited. Describe how the configuration settings of the secure channel verified that ‘split tunneling’ is prohibited:
<Report Findings Here> 5D-3.2.b Observe a Host System administrator log on to the device which provides non-console access to the Host System to verify that “split tunneling” is prohibited.
Describe how the Host System administrator’s log on to the device verified that ‘split tunneling’ is prohibited:
<Report …
Added
p. 88
5D-3.4.a Examine documented policies and procedures to verify that a process is defined to authorize systems for non-console access, and not permit access until such times that authorization has been granted.
Documented policies and procedures reviewed: <Report Findings Here> 5D-3.4.b For a sample of systems, examine device configurations to verify that non-console access is permitted only from the authorized systems. Sample of systems reviewed: <Report Findings Here> Describe how device configurations for the sample of systems verified that non- console access is permitted only from the authorized systems:
<Report Findings Here> 5D-3.5 Non-console access to the Host System must only be permitted from a PCI DSS compliant environment.
5D-3.5 Verify that non-console access to the Host System is only permitted from a PCI DSS compliant environment, including 5D-3.5.1 through 5D-3.5.2 Review solution provider documentation, including data flow diagrams, and perform the following:
<Report Findings Here> 5D-3.5.1 The authorized system (e.g., workstation) from which non-console …
Documented policies and procedures reviewed: <Report Findings Here> 5D-3.4.b For a sample of systems, examine device configurations to verify that non-console access is permitted only from the authorized systems. Sample of systems reviewed: <Report Findings Here> Describe how device configurations for the sample of systems verified that non- console access is permitted only from the authorized systems:
<Report Findings Here> 5D-3.5 Non-console access to the Host System must only be permitted from a PCI DSS compliant environment.
5D-3.5 Verify that non-console access to the Host System is only permitted from a PCI DSS compliant environment, including 5D-3.5.1 through 5D-3.5.2 Review solution provider documentation, including data flow diagrams, and perform the following:
<Report Findings Here> 5D-3.5.1 The authorized system (e.g., workstation) from which non-console …
Added
p. 89
Sample of access control records reviewed: <Report Findings Here> Describe how the sample of access control records compared to Host System settings verified that non-console access to the Host System is only provided to authorized users:
<Report Findings Here> 5D-3.7 Non-console sessions to the Host System must be terminated after 15 minutes of inactivity.
5D-3.7.a Review documented policies and procedures to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
Documented policies and procedures reviewed: <Report Findings Here> 5D-3.7.b Inspect the system configuration settings to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
Describe how system configuration settings verified that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity:
<Report Findings Here> 5D-4.1 The Host System must be located within a physically secure room that is dedicated to decryption operations and transaction processing.
5D-4.1 Observe the …
<Report Findings Here> 5D-3.7 Non-console sessions to the Host System must be terminated after 15 minutes of inactivity.
5D-3.7.a Review documented policies and procedures to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
Documented policies and procedures reviewed: <Report Findings Here> 5D-3.7.b Inspect the system configuration settings to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
Describe how system configuration settings verified that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity:
<Report Findings Here> 5D-4.1 The Host System must be located within a physically secure room that is dedicated to decryption operations and transaction processing.
5D-4.1 Observe the …
Added
p. 90
Logs must be retained for a minimum of three years.
Logs must be regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein.
Log reviews must be documented.
Logs must include but not be limited to:
- Logs of access to the room from a badge access system
- Logs of access to the room from a manual sign-in sheet 5D-4.3.a Examine documented policies and procedures to verify all physical access to the secure room must be monitored and logs must be maintained.
Policies and procedures must require the following:
Logs are retained for a minimum of three years.
Logs are regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein.
Log reviews are documented.
Log reviews are documented.
Logs include at a minimum:
Logs include at a minimum:
- Access to the …
Logs must be regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein.
Log reviews must be documented.
Logs must include but not be limited to:
- Logs of access to the room from a badge access system
- Logs of access to the room from a manual sign-in sheet 5D-4.3.a Examine documented policies and procedures to verify all physical access to the secure room must be monitored and logs must be maintained.
Policies and procedures must require the following:
Logs are retained for a minimum of three years.
Logs are regularly reviewed by an authorized person who does not have access to the secure room or to the systems therein.
Log reviews are documented.
Log reviews are documented.
Logs include at a minimum:
Logs include at a minimum:
- Access to the …
Added
p. 91
5D-4.5.a Examine documented policies and procedures to verify that physical access to the secure room is only permitted to designated personnel with defined business needs and duties.
Documented policies and procedures reviewed: <Report Findings Here> 5D-4.5.b Examine the list of designated personnel and interview responsible personnel to verify that only personnel with defined business needs and duties are permitted access to the secure room.
Documented list of designated personnel: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 5D-4.5.c Examine physical access controls to verify that physical access to the secure room is only permitted to pre-designated personnel with defined business needs and duties.
Describe how physical access controls verified that physical access to the secure room is only permitted to pre-designated personnel with defined business needs and duties:
<Report Findings Here> 5D-4.6 The secure room must be monitored via CCTV on a 24-hour basis. This must include, as a minimum, the following areas:
…
Documented policies and procedures reviewed: <Report Findings Here> 5D-4.5.b Examine the list of designated personnel and interview responsible personnel to verify that only personnel with defined business needs and duties are permitted access to the secure room.
Documented list of designated personnel: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 5D-4.5.c Examine physical access controls to verify that physical access to the secure room is only permitted to pre-designated personnel with defined business needs and duties.
Describe how physical access controls verified that physical access to the secure room is only permitted to pre-designated personnel with defined business needs and duties:
<Report Findings Here> 5D-4.6 The secure room must be monitored via CCTV on a 24-hour basis. This must include, as a minimum, the following areas:
…
Added
p. 92
If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
5D-4.8.a Examine a sample of recordings to verify that at least the most recent 45 days of images are securely archived. Sample of CCTV recordings reviewed: <Report Findings Here> 5D-4.8.b If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45- day period.
Describe how system configurations observed verified that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period:
<Report Findings Here> 5D-4.9 Personnel with access to the secure room must not have access to the media (e.g., VCR tapes, digital recording systems, etc.) with the recorded surveillance data.
5D-4.9.a Examine documented access …
5D-4.8.a Examine a sample of recordings to verify that at least the most recent 45 days of images are securely archived. Sample of CCTV recordings reviewed: <Report Findings Here> 5D-4.8.b If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45- day period.
Describe how system configurations observed verified that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period:
<Report Findings Here> 5D-4.9 Personnel with access to the secure room must not have access to the media (e.g., VCR tapes, digital recording systems, etc.) with the recorded surveillance data.
5D-4.9.a Examine documented access …
Added
p. 93
Continuous (24/7) physical intrusion-detection monitoring of the secure room.
The physical intrusion-detection must be connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
Documented security policies and procedures reviewed: <Report Findings Here> 5D-4.11.b Observe the physical intrusion-detection system to verify that it:
Provides continuous (24/7) monitoring of the secure room.
Provides continuous (24/7) monitoring of the secure room.
It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
Describe how the physical intrusion-detection system verified that it:
<Report Findings Here> 5D-4.12 Any windows in the secure room must be locked, protected by alarmed sensors, or otherwise similarly secured.
5D-4.12.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors. Identify …
The physical intrusion-detection must be connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
Documented security policies and procedures reviewed: <Report Findings Here> 5D-4.11.b Observe the physical intrusion-detection system to verify that it:
Provides continuous (24/7) monitoring of the secure room.
Provides continuous (24/7) monitoring of the secure room.
It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
It is connected to the alarm system and automatically activated whenever all authorized personnel have exited the secure room.
Describe how the physical intrusion-detection system verified that it:
<Report Findings Here> 5D-4.12 Any windows in the secure room must be locked, protected by alarmed sensors, or otherwise similarly secured.
5D-4.12.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors. Identify …
Added
p. 94
5D-4.15.a Examine security policies and procedures to verify they require that all alarm events are logged. Documented security policies and procedures reviewed: <Report Findings Here> 5D-4.15.b Examine security-system configurations and documented alarm events to verify that all alarm events are logged. Describe how security-system configurations and documented alarm events verified that all alarm events are logged:
<Report Findings Here> 5D-4.16 Documented alarm events must be signed off by an authorized person who was not involved in the event.
5D-4.16.a Examine security policies and procedures to verify alarm events must be signed off by an authorized person other than the individual who was involved in the event.
Documented security policies and procedures reviewed: <Report Findings Here> 5D-4.16.b For a sample of documented alarm events, interview personnel who signed off on the event to verify that person was not involved in the event. Sample of documented alarm events reviewed: <Report Findings Here> Signing personnel interviewed: …
<Report Findings Here> 5D-4.16 Documented alarm events must be signed off by an authorized person who was not involved in the event.
5D-4.16.a Examine security policies and procedures to verify alarm events must be signed off by an authorized person other than the individual who was involved in the event.
Documented security policies and procedures reviewed: <Report Findings Here> 5D-4.16.b For a sample of documented alarm events, interview personnel who signed off on the event to verify that person was not involved in the event. Sample of documented alarm events reviewed: <Report Findings Here> Signing personnel interviewed: …
Added
p. 95
Describe how system configurations for access, intrusion-detection, and monitoring (camera) systems verified that time and date stamps are synchronized:
<Report Findings Here> 5D-4.19.c Examine a sample of logs from the access, intrusion-detection, and monitoring (camera) systems to verify log time and date stamps are synchronized.
Sample of logs from the access, intrusion-detection, and monitoring (camera) systems:
<Report Findings Here> 5D-4.19.1 If a manual synchronization process is used, synchronization must occur at least quarterly, and documentation of the synchronization must be retained for at least a one-year period.
5D-4.19.1.a If a manual synchronization process is implemented, interview responsible personnel and examine records of synchronization to verify the mechanism is performed at least quarterly.
Responsible personnel interviewed: <Report Findings Here> Records of synchronization examined: <Report Findings Here> 5D-4.19.1.b Examine records of the synchronization process to verify that documentation is retained for at least one year. Records of synchronization examined: <Report Findings Here> 5D-4.20 The entrance to the …
<Report Findings Here> 5D-4.19.c Examine a sample of logs from the access, intrusion-detection, and monitoring (camera) systems to verify log time and date stamps are synchronized.
Sample of logs from the access, intrusion-detection, and monitoring (camera) systems:
<Report Findings Here> 5D-4.19.1 If a manual synchronization process is used, synchronization must occur at least quarterly, and documentation of the synchronization must be retained for at least a one-year period.
5D-4.19.1.a If a manual synchronization process is implemented, interview responsible personnel and examine records of synchronization to verify the mechanism is performed at least quarterly.
Responsible personnel interviewed: <Report Findings Here> Records of synchronization examined: <Report Findings Here> 5D-4.19.1.b Examine records of the synchronization process to verify that documentation is retained for at least one year. Records of synchronization examined: <Report Findings Here> 5D-4.20 The entrance to the …
Added
p. 96
Types/models of HSMs Number of HSMs deployed and any change in numbers since last report Date of last physical inspection of HSMs Date/status of last PCI DSS assessment Details of any suspicious activity that occurred, per 5C-1.2 5E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel, and to confirm that the following processes are documented and implemented:
Providing reports annually and upon significant changes Types/models of HSMs Number of HSMs deployed and description of any changes since last Date of last physical inspection of HSMs Date/status of last PCI DSS assessment Details of any suspicious activity that occurred, per 5C-1.2 Component provider’s documented procedures <Report Findings Here> Responsible component provider personnel interviewed: <Report Findings Here> 5E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the …
Providing reports annually and upon significant changes Types/models of HSMs Number of HSMs deployed and description of any changes since last Date of last physical inspection of HSMs Date/status of last PCI DSS assessment Details of any suspicious activity that occurred, per 5C-1.2 Component provider’s documented procedures <Report Findings Here> Responsible component provider personnel interviewed: <Report Findings Here> 5E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the …
Added
p. 97
Critical infrastructure changes, including to the PCI DSS environment Changes to PCI DSS compliance status Additions and/or removal of HSM types Component provider’s documented procedures <Report Findings Here> Responsible component provider personnel interviewed: <Report Findings Here> 5E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:
Critical infrastructure changes, including to the PCI DSS environment Changes to PCI DSS compliance status Additions and/or removal of HSM types.
Critical infrastructure changes, including to the PCI DSS environment Changes to PCI DSS compliance status Additions and/or removal of HSM types.
Added
p. 98
6A-1 Account data is protected with appropriate cryptographic algorithms, key sizes and strengths, and key-management processes.
6B Account-data keys and key-management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
6B-1 All keys and key components are generated using an approved random or pseudo-random process.
6B-2 Compromise of the key generation process must not be possible without collusion between at least two trusted individuals.
6B-3 Documented procedures must exist and must be demonstrably in use for all key-generation processing.
6C Keys are conveyed or transmitted in a secure manner.
6C-1 Secret or private keys shall be transferred by:
a) Physically forwarding the key as at least two separate key shares or full-length components (hard copy, smart card, SCD) using different communication channels, or
b) Transmitting the key in ciphertext form.
Public keys must be conveyed in a manner that protects their integrity …
6B Account-data keys and key-management methodologies are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
6B-1 All keys and key components are generated using an approved random or pseudo-random process.
6B-2 Compromise of the key generation process must not be possible without collusion between at least two trusted individuals.
6B-3 Documented procedures must exist and must be demonstrably in use for all key-generation processing.
6C Keys are conveyed or transmitted in a secure manner.
6C-1 Secret or private keys shall be transferred by:
a) Physically forwarding the key as at least two separate key shares or full-length components (hard copy, smart card, SCD) using different communication channels, or
b) Transmitting the key in ciphertext form.
Public keys must be conveyed in a manner that protects their integrity …
Added
p. 98
6C-4 Documented procedures must exist and must be demonstrably in use for all key transmission and conveyance processing.
Added
p. 99
6D-1 Secret and private keys must be input into hardware (host) security modules (HSMs) and Point of Interaction (POI) devices in a secure manner.
a) Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge.
b) Key-establishment techniques using public-key cryptography must be implemented securely.
6D-2 The mechanisms used to load secret and private keys•such as terminals, external PIN pads, key guns, or similar devices and methods•must be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component.
6D-3 All hardware and access/authentication mechanisms (e.g., passwords) used for key loading or the signing of authenticated applications (e.g., for “whitelists”) must be managed under dual control.
a) Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge.
b) Key-establishment techniques using public-key cryptography must be implemented securely.
6D-2 The mechanisms used to load secret and private keys•such as terminals, external PIN pads, key guns, or similar devices and methods•must be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component.
6D-3 All hardware and access/authentication mechanisms (e.g., passwords) used for key loading or the signing of authenticated applications (e.g., for “whitelists”) must be managed under dual control.
Added
p. 99
6D-5 Documented procedures must exist and be demonstrably in use (including audit trails) for all key-loading activities.
Added
p. 99
6E-1 Unique, secret cryptographic keys must be in use for each identifiable link between host computer systems of two organizations or logically separate systems within the same organization.
Added
p. 100
6F-3 Keys generated using reversible key-calculation methods, such as key variants, must only be used in SCDs that possess the original key.
Keys generated using reversible key-calculation methods must not be used at different levels of the key hierarchy. For example, a variant of a key-encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.
Keys generated with a non-reversible process, such as key derivation or transformation process with a base key using an encipherment process, are not subject to these requirements.
6F-4 Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.
Keys generated using reversible key-calculation methods must not be used at different levels of the key hierarchy. For example, a variant of a key-encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.
Keys generated with a non-reversible process, such as key derivation or transformation process with a base key using an encipherment process, are not subject to these requirements.
6F-4 Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.
Added
p. 100
6F-6 Logs must be kept for any time that keys, key components or related materials are removed from storage or loaded to an SCD.
6F-7 Backups of secret and private keys must exist only for the purpose of reinstating keys that are accidentally destroyed or are otherwise inaccessible. The backups must exist only in one if the allowed storage forms for that key.
Note: It is not a requirement to have backup copies of key components or keys.
6F-8 Documented procedures must exist and must be demonstrably in use for all key-administration operations.
6F-7 Backups of secret and private keys must exist only for the purpose of reinstating keys that are accidentally destroyed or are otherwise inaccessible. The backups must exist only in one if the allowed storage forms for that key.
Note: It is not a requirement to have backup copies of key components or keys.
6F-8 Documented procedures must exist and must be demonstrably in use for all key-administration operations.
Added
p. 101
6G-1 Equipment used to protect account data (e.g., POI devices and HSMs) must be placed into service only if there is assurance that the equipment has not been substituted or subjected to unauthorized modifications or tampering prior to the deployment of the device
•both prior to and subsequent to the loading of cryptographic keys
•and that precautions are taken to minimize the threat of compromise once deployed.
6G-2 Not used in Domain 6 but is used in Annex B 6G-3 Procedures must be in place and implemented to protect and SCDs•and endure the destruction of any cryptographic keys or key material within such devices•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.
6G-4 Any SCD capable of encrypting a key and producing cryptograms (i.e., and HSM or key-injection/loading device) of that key, or signing applications to be loaded onto a POI device, must be protected against unauthorized …
•both prior to and subsequent to the loading of cryptographic keys
•and that precautions are taken to minimize the threat of compromise once deployed.
6G-2 Not used in Domain 6 but is used in Annex B 6G-3 Procedures must be in place and implemented to protect and SCDs•and endure the destruction of any cryptographic keys or key material within such devices•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.
6G-4 Any SCD capable of encrypting a key and producing cryptograms (i.e., and HSM or key-injection/loading device) of that key, or signing applications to be loaded onto a POI device, must be protected against unauthorized …
Added
p. 102
Table 6.1
• Key Matrix. List of all cryptographic keys (by type) used in P2PE Solution description: Description of level in the key hierarchy:
Purpose/function of the key (including types of devices using key):
Key-creation method: How key is distributed
• e.g. manually via courier, and/or via remote key distribution (Annex A) and/or via KIF (Annex B)*: media used Method of key destruction:
* Note: Keys distributed by remote key distribution must be included in Annex A; keys distributed via injection must be included in Annex B.
Table 6.2
• List of devices used to generate keys or key components All keys identified in Table 6.1 must be included in Table 6.2 Device name/ identifier: Manufacturer/ Model: Type of key(s) generated (per
Table 6.1): location: Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) PTS or FIPS approval number, or other certification details:
Domain 6: P2PE Cryptographic Key Operations and Device Management
• Reporting Requirements and Testing Procedures …
• Key Matrix. List of all cryptographic keys (by type) used in P2PE Solution description: Description of level in the key hierarchy:
Purpose/function of the key (including types of devices using key):
Key-creation method: How key is distributed
• e.g. manually via courier, and/or via remote key distribution (Annex A) and/or via KIF (Annex B)*: media used Method of key destruction:
* Note: Keys distributed by remote key distribution must be included in Annex A; keys distributed via injection must be included in Annex B.
Table 6.2
• List of devices used to generate keys or key components All keys identified in Table 6.1 must be included in Table 6.2 Device name/ identifier: Manufacturer/ Model: Type of key(s) generated (per
Table 6.1): location: Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) PTS or FIPS approval number, or other certification details:
Domain 6: P2PE Cryptographic Key Operations and Device Management
• Reporting Requirements and Testing Procedures …
Added
p. 103
Describe how observed key-management operations and devices verified that all cryptographic algorithms and key sizes are in accordance with Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms:
<Report Findings Here> 6A-1.2 Cryptographic-key changes must be implemented for keys that have reached the end of their crypto-period (e.g., after a defined period of time and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (e.g., NIST Special Publication 800-57).
See Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
6A-1.2.a Examine documented key-management procedures to verify:
Crypto-periods are defined for every type of key in use.
Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication 800-57).
A process/methodology is in place to determine when the crypto-period is reached for …
<Report Findings Here> 6A-1.2 Cryptographic-key changes must be implemented for keys that have reached the end of their crypto-period (e.g., after a defined period of time and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (e.g., NIST Special Publication 800-57).
See Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
6A-1.2.a Examine documented key-management procedures to verify:
Crypto-periods are defined for every type of key in use.
Crypto-periods are based on industry best practices and guidelines (e.g., NIST Special Publication 800-57).
A process/methodology is in place to determine when the crypto-period is reached for …
Added
p. 104
Key type/description Description of level in the key hierarchy Purpose/function of the key (including type of devices using key) Key-creation method Key-distribution method (e.g., manually via courier, remote key distribution) Type of media used for key storage Key-destruction method 6A-1.3.1.a Examine key management policies and procedures and verify documentation of all cryptographic keys managed as part of the P2PE solution is required, and includes:
Key type/description Description of level in the key hierarchy Purpose/function of the key (including type of devices using key) Key-creation method Key-distribution method (e.g., manually via courier, remote key distribution) Type of media used for key storage Key-destruction method Documented key management policies and procedures reviewed: <Report Findings Here> 6A-1.3.1.b Observe documentation and interview personnel and confirm that documentation of all cryptographic keys managed as part of the P2PE solution exists, and includes:
…
Key type/description Description of level in the key hierarchy Purpose/function of the key (including type of devices using key) Key-creation method Key-distribution method (e.g., manually via courier, remote key distribution) Type of media used for key storage Key-destruction method Documented key management policies and procedures reviewed: <Report Findings Here> 6A-1.3.1.b Observe documentation and interview personnel and confirm that documentation of all cryptographic keys managed as part of the P2PE solution exists, and includes:
…
Added
p. 105
Device name/identifier Device manufacturer/model Type of keys generated (per 6A-1.3.1) Device location Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documented key management policies and procedures reviewed: <Report Findings Here> 6A-1.3.2.b Observe documentation and interview personnel and confirm that a list of all devices used to generate keys managed as part of the P2PE solution exists, and includes:
Device name/identifier Device manufacturer/model Type of keys generated (per 6A-1.3.1) Device location Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 6B-1.1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys.
Cryptographic keys or key components must be generated by one of the following:
An approved key-generation function of a …
Device name/identifier Device manufacturer/model Type of keys generated (per 6A-1.3.1) Device location Approved key-generation function (PTS, FIPS, or other approved per NIST SP800-22) Documentation reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 6B-1.1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys.
Cryptographic keys or key components must be generated by one of the following:
An approved key-generation function of a …
Added
p. 106
An approved key-generation function of a PCI•approved HSM or POI An approved key-generation function of a FIPS 140-2 Level 3 (or higher) An approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 Certification letters/technical documentation reviewed: <Report Findings Here> 6B-1.1.c Observe devices performing key-generation functions, including validation of firmware used. Describe how the reviewed devices used for key generation verified that devices are as noted above, including validation of the firmware:
<Report Findings Here> 6B-2.1 Implement security controls, including dual control and tamper protection to prevent the unauthorized disclosure of keys/key components.
6B-2.1 Perform the following:
6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or …
<Report Findings Here> 6B-2.1 Implement security controls, including dual control and tamper protection to prevent the unauthorized disclosure of keys/key components.
6B-2.1 Perform the following:
6B-2.1.1 Any clear-text output of the key-generation process must be overseen by at least two authorized individuals who ensure there is no unauthorized mechanism that might disclose a clear-text key or key component as it is transferred between the key-generation SCD and the device or …
Added
p. 106
There is no unauthorized mechanism that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component.
Added
p. 107
There is no mechanism (including connectivity) that might disclose a clear- text key or key component between the key-generation device and the device or medium receiving the key or key component.
Responsible personnel interviewed: <Report Findings Here> Describe how the key-generations processes observed verified that any clear- text output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key:
<Report Findings Here> Describe how the key-generations processes observed verified that there is no mechanism (including connectivity) that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component:
<Report Findings Here> 6B-2.1.2 There must be no point in the process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for …
Responsible personnel interviewed: <Report Findings Here> Describe how the key-generations processes observed verified that any clear- text output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key:
<Report Findings Here> Describe how the key-generations processes observed verified that there is no mechanism (including connectivity) that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component:
<Report Findings Here> 6B-2.1.2 There must be no point in the process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for …
Added
p. 108
Documented key-generation procedures reviewed: <Report Findings Here> 6B-2.1.4.b Observe key-generation set-up processes for all key types to verify that key-generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering.
Describe how the key-generation set-up processes observed verified that key- generation equipment is inspected prior to use to ensure equipment does not show any signs of tampering:
<Report Findings Here> 6B-2.1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the key-generation area It must not be feasible to observe the key-component/key-generation process whereby clear-text keying material is observable either directly or via camera monitoring 6B-2.1.5.a Examine documentation to verify that physical security controls are defined to ensure the key component/key-generation process cannot be observed or accessed by unauthorized personnel.
Documentation reviewed: <Report Findings Here> 6B-2.1.5.b Observe the physical security controls to verify that key- component/key-generation process cannot be observed or accessed by unauthorized …
Describe how the key-generation set-up processes observed verified that key- generation equipment is inspected prior to use to ensure equipment does not show any signs of tampering:
<Report Findings Here> 6B-2.1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the key-generation area It must not be feasible to observe the key-component/key-generation process whereby clear-text keying material is observable either directly or via camera monitoring 6B-2.1.5.a Examine documentation to verify that physical security controls are defined to ensure the key component/key-generation process cannot be observed or accessed by unauthorized personnel.
Documentation reviewed: <Report Findings Here> 6B-2.1.5.b Observe the physical security controls to verify that key- component/key-generation process cannot be observed or accessed by unauthorized …
Added
p. 109
Printers used for this purpose must not be used for other purposes.
6B-2.3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed immediately after printing such that:
Documented procedures for printed key components reviewed: <Report Findings Here> 6B-2.3.b Observe processes for printing key components to verify that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output.
Describe how the processes observed for printing key components verified that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output:
<Report Findings Here> 6B-2.3.c Observe blind mailers or other sealed containers used for key components to verify that tampering can be visually detected. Describe how blind mailers or …
6B-2.3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed immediately after printing such that:
Documented procedures for printed key components reviewed: <Report Findings Here> 6B-2.3.b Observe processes for printing key components to verify that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output.
Describe how the processes observed for printing key components verified that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output:
<Report Findings Here> 6B-2.3.c Observe blind mailers or other sealed containers used for key components to verify that tampering can be visually detected. Describe how blind mailers or …
Added
p. 110
Describe how the destruction process of the identified key residue verified that any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation:
<Report Findings Here> If a key is generated in a separate device before being exported into the end- use device, describe how the destruction process of the identified key residue verified that the key and all related critical security parameters are deleted from the generation and/or injection device immediately after the transfer to the device that will use the key:
<Report Findings Here> 6B-2.5 Asymmetric-key pairs must either be:
Generated by the device that will use the key pair; or If generated externally, the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair 6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that …
<Report Findings Here> If a key is generated in a separate device before being exported into the end- use device, describe how the destruction process of the identified key residue verified that the key and all related critical security parameters are deleted from the generation and/or injection device immediately after the transfer to the device that will use the key:
<Report Findings Here> 6B-2.5 Asymmetric-key pairs must either be:
Generated by the device that will use the key pair; or If generated externally, the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair 6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that …
Added
p. 110
Describe how the key-generation processes observed verified that asymmetric- key pairs are either:
Added
p. 111
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Affixing (e.g., taping) key or component values to or inside devices Writing key or component values in procedure manuals 6B-2.6.a Examine documented policy and procedures to verify that clear-text private or secret keys or their components are prohibited from being transmitted across insecure channels, including but not limited to:
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into …
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text private or secret keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into …
Added
p. 112
Responsible personnel interviewed: <Report Findings Here> 6B-3.1.c Observe key-generation ceremonies, whether actual or for demonstration purposes, and verify that the documented procedures are demonstrably in use.
Describe how the actual or demonstrative key-generation ceremonies verified that the documented procedures are demonstrably in use:
<Report Findings Here> 6B-3.2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs.
6B-3.2.a Examine documented key-generation procedures to verify that key- generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) are logged.
Documented key-generation procedures reviewed: <Report Findings Here> 6B-3.2.b Observe demonstrations for the generation of higher-level keys to verify that all key-generation events are logged. Describe how the demonstrations for the generation of higher-level keys verified that all key-generation events are logged:
<Report Findings Here> 6B-3.2.c Examine logs of key generation to verify that exchanges of higher-level …
Describe how the actual or demonstrative key-generation ceremonies verified that the documented procedures are demonstrably in use:
<Report Findings Here> 6B-3.2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs.
6B-3.2.a Examine documented key-generation procedures to verify that key- generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) are logged.
Documented key-generation procedures reviewed: <Report Findings Here> 6B-3.2.b Observe demonstrations for the generation of higher-level keys to verify that all key-generation events are logged. Describe how the demonstrations for the generation of higher-level keys verified that all key-generation events are logged:
<Report Findings Here> 6B-3.2.c Examine logs of key generation to verify that exchanges of higher-level …
Added
p. 112
Components of encryption keys must be transferred using different communication channels, such as different courier services. It is not sufficient to send key components for a specific key on different days using the same communication channel.
Added
p. 113
<Report Findings Here> 6C-1.1.b If key components are ever transmitted in clear-text using pre- numbered, tamper-evident, authenticable mailers, perform the following:
Added
p. 113
Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
Examine documented procedures to verify that cryptographic-key components are transferred using different communications channels.
Examine records of key conveyances and interview responsible personnel to verify that cryptographic key components are transferred using different communications channels.
Examine documented procedures to verify that serial numbers are verified prior to the usage of the keying material.
Documented procedures reviewed: <Report Findings Here> Records of key conveyances examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the method used to transport clear-text key components using tamper-evident mailers verified that details of the serial number of the package are transmitted separately from the package itself:
Examine documented procedures to verify that the mechanisms to obtain the keying material …
Examine documented procedures to verify that cryptographic-key components are transferred using different communications channels.
Examine records of key conveyances and interview responsible personnel to verify that cryptographic key components are transferred using different communications channels.
Examine documented procedures to verify that serial numbers are verified prior to the usage of the keying material.
Documented procedures reviewed: <Report Findings Here> Records of key conveyances examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the method used to transport clear-text key components using tamper-evident mailers verified that details of the serial number of the package are transmitted separately from the package itself:
Examine documented procedures to verify that the mechanisms to obtain the keying material …
Added
p. 113
Examine records of key transfers and interview responsible personnel to verify that the mechanisms to obtain the keying material are conveyed using separate communication channels.
Documented procedures reviewed: <Report Findings Here> Records of key transfers examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Documented procedures reviewed: <Report Findings Here> Records of key transfers examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Added
p. 114
Any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component or shares sufficient to form the necessary threshold to derive the key.
Any person with access to the media conveying a component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key.
Documented procedures reviewed: <Report Findings Here> 6C-1.2.b Observe key-transfer processes and interview personnel to verify that controls are implemented to ensure that no single person can ever have access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify …
Any person with access to the media conveying a component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other component of this key that is sufficient to form the necessary threshold to derive the key.
Documented procedures reviewed: <Report Findings Here> 6C-1.2.b Observe key-transfer processes and interview personnel to verify that controls are implemented to ensure that no single person can ever have access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify …
Added
p. 114
Personnel interviewed: <Report Findings Here> Describe how the implemented controls for the key-transfer processes observed verified that:
<Report Findings Here> 6C-1.2.c Examine documented procedures and interview responsible personnel to verify that the method used does not allow for any personnel to have access to all components.
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.2.d Observe the method used to transport key components to verify that the method does not allow for any personnel to have access to all components. Describe how the method used to transport key components verified that it does not allow for any personnel to have access to all components:
<Report Findings Here> 6C-1.2.c Examine documented procedures and interview responsible personnel to verify that the method used does not allow for any personnel to have access to all components.
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6C-1.2.d Observe the method used to transport key components to verify that the method does not allow for any personnel to have access to all components. Describe how the method used to transport key components verified that it does not allow for any personnel to have access to all components:
Added
p. 115
Other similar mechanisms, such as SMS, fax, or telephone shall not be used to convey clear-text key values.
6C-1.3 Validate through interviews, observation, and logs that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components.
Personnel interviewed: <Report Findings Here> Logs reviewed: <Report Findings Here> Describe the observations that confirmed that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components:
<Report Findings Here> 6C-1.4 Public keys must be conveyed in a manner that protects their integrity and authenticity.
Examples of acceptable methods include:
Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A A hash of the public key sent by a separate channel (e.g., mail) Using a MAC (message authentication code) created using the …
6C-1.3 Validate through interviews, observation, and logs that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components.
Personnel interviewed: <Report Findings Here> Logs reviewed: <Report Findings Here> Describe the observations that confirmed that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components:
<Report Findings Here> 6C-1.4 Public keys must be conveyed in a manner that protects their integrity and authenticity.
Examples of acceptable methods include:
Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A A hash of the public key sent by a separate channel (e.g., mail) Using a MAC (message authentication code) created using the …
Added
p. 116
Responsible personnel interviewed: <Report Findings Here> Describe how the process for conveying public keys verified that the implemented method ensures public keys are conveyed in a manner that protects their integrity and authenticity:
<Report Findings Here> 6C-2.1 Any single clear-text secret or private key component/share must at all times be either:
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or Contained within a physically secure SCD.
Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key.
6C-2.1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that …
<Report Findings Here> 6C-2.1 Any single clear-text secret or private key component/share must at all times be either:
Under the continuous supervision of a person with authorized access to this component, or Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, unauthorized access to it would be detected, or Contained within a physically secure SCD.
Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key.
6C-2.1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that …
Added
p. 117
The set of components Any keys encrypted under this (combined) key 6C-2.2.a Verify documented procedures include requirements for all packaging or mailers containing clear-text key components to be examined for evidence of tampering before being opened.
Documented procedures reviewed: <Report Findings Here> 6C-2.2.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened.
Responsible personnel interviewed: <Report Findings Here> Describe how the observed processes verified that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened:
<Report Findings Here> 6C-2.2.c Verify documented procedures require that any sign of package tampering results in the destruction and replacement of both:
The set of components Any keys encrypted under this (combined) key Documented procedures reviewed: <Report Findings Here> 6C-2.2.d Interview responsible personnel and observe processes to verify that if a …
Documented procedures reviewed: <Report Findings Here> 6C-2.2.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened.
Responsible personnel interviewed: <Report Findings Here> Describe how the observed processes verified that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened:
<Report Findings Here> 6C-2.2.c Verify documented procedures require that any sign of package tampering results in the destruction and replacement of both:
The set of components Any keys encrypted under this (combined) key Documented procedures reviewed: <Report Findings Here> 6C-2.2.d Interview responsible personnel and observe processes to verify that if a …
Added
p. 118
Physical access logs examined: <Report Findings Here> 6C-2.4 Mechanisms must exist to ensure that only authorized custodians:
Place key components into pre-numbered tamper-evident, authenticable packaging for transmittal.
Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident authenticable packaging containing key components.
Place key components into pre-numbered tamper-evident, authenticable packaging for transmittal.
Check tamper-evident packaging upon receipt for signs of tamper prior to opening tamper-evident authenticable packaging containing key components.
Added
p. 118
6C-2.4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:
Added
p. 118
Documentation reviewed: <Report Findings Here> 6C-2.4.b Observe implemented mechanisms and processes to verify that only the authorized key custodians can perform the following:
Describe how the implemented mechanisms and processes observed verified that only the authorized key custodians can perform the following:
<Report Findings Here> 6C-2.5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
Note: Numbered courier bags are not sufficient for this purpose 6C-2.5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the method used to transport clear-text key components using tamper-evident mailers verified that details of the serial …
Describe how the implemented mechanisms and processes observed verified that only the authorized key custodians can perform the following:
<Report Findings Here> 6C-2.5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
Note: Numbered courier bags are not sufficient for this purpose 6C-2.5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Describe how the method used to transport clear-text key components using tamper-evident mailers verified that details of the serial …
Added
p. 119
DEA keys used for encrypting keys must be at least double-length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
A double- or triple-length DEA key must not be encrypted with a DEA key of lesser strength.
TDEA keys shall not be used to protect AES keys.
TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
RSA keys encrypting keys greater in strength than 80 bits shall have bit strength of at least 112 bits.
6C-3.1.a Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed, as delineated in Annex C.
Documented procedures reviewed: <Report Findings Here> 6C-3.1.b Observe key-generation processes to verify that all keys used to transmit or convey other cryptographic keys are …
A double- or triple-length DEA key must not be encrypted with a DEA key of lesser strength.
TDEA keys shall not be used to protect AES keys.
TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
RSA keys encrypting keys greater in strength than 80 bits shall have bit strength of at least 112 bits.
6C-3.1.a Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed, as delineated in Annex C.
Documented procedures reviewed: <Report Findings Here> 6C-3.1.b Observe key-generation processes to verify that all keys used to transmit or convey other cryptographic keys are …
Added
p. 120
6C-4.1.a Verify documented procedures exist for all key transmission and conveyance processing. Documented procedures reviewed: <Report Findings Here> 6C-4.1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for key transmission and conveyance processing.
Responsible personnel interviewed: <Report Findings Here> 6C-4.2 Methods used for the conveyance or receipt of keys must be documented.
6C-4.2 Verify documented procedures include all methods used for the conveyance or receipt of keys. Documented procedures reviewed: <Report Findings Here> 6D-1.1 The loading of secret or private keys, when from the individual key components or shares, must be performed using the principles of dual control and split knowledge.
Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens.
6D-1.1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required. Documented …
Responsible personnel interviewed: <Report Findings Here> 6C-4.2 Methods used for the conveyance or receipt of keys must be documented.
6C-4.2 Verify documented procedures include all methods used for the conveyance or receipt of keys. Documented procedures reviewed: <Report Findings Here> 6D-1.1 The loading of secret or private keys, when from the individual key components or shares, must be performed using the principles of dual control and split knowledge.
Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens.
6D-1.1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required. Documented …
Added
p. 121
Dual control must be implemented using one or more of, but not limited to, the following techniques:
Two or more passwords of five characters or more (vendor default values must be changed) Multiple cryptographic tokens (such as smartcards), or physical keys Physical access controls Note that for devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
6D-1.3.a Examine documented procedures for loading of clear-text cryptographic keys to verify they require dual control to authorize any key- loading session.
Documented procedures reviewed: <Report Findings Here> 6D-1.3.b For all types of production SCDs, observe processes for loading clear- text cryptographic keys to verify that dual control is required to authorize any key-loading session. Verify that any passwords used are a minimum of five characters.
Describe how the observed processes …
Two or more passwords of five characters or more (vendor default values must be changed) Multiple cryptographic tokens (such as smartcards), or physical keys Physical access controls Note that for devices that do not support two or more passwords, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian.
6D-1.3.a Examine documented procedures for loading of clear-text cryptographic keys to verify they require dual control to authorize any key- loading session.
Documented procedures reviewed: <Report Findings Here> 6D-1.3.b For all types of production SCDs, observe processes for loading clear- text cryptographic keys to verify that dual control is required to authorize any key-loading session. Verify that any passwords used are a minimum of five characters.
Describe how the observed processes …
Added
p. 122
6D-1.5 Examine vendor documentation describing options for how the HSM MFK is created. Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review.
Vendor documentation reviewed: <Report Findings Here> Identify the P2PE Assessor who corroborated how the HSM MFK is <Report Findings Here> 6D-1.6 Any other SCD loaded with the same key components must combine all entered key components using the identical process.
6D-1.6 Through examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe the observations that confirmed that any devices that are loaded with the same key components use the same mathematical process to derive the final key:
<Report Findings Here> 6D-1.7 The initial terminal master key (TMK) must …
Vendor documentation reviewed: <Report Findings Here> Identify the P2PE Assessor who corroborated how the HSM MFK is <Report Findings Here> 6D-1.6 Any other SCD loaded with the same key components must combine all entered key components using the identical process.
6D-1.6 Through examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe the observations that confirmed that any devices that are loaded with the same key components use the same mathematical process to derive the final key:
<Report Findings Here> 6D-1.7 The initial terminal master key (TMK) must …
Added
p. 123
Documentation reviewed: <Report Findings Here> 6D 1.8.b If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, verify that the requirements detailed in Annex A of this document are met, including:
Use of public and private key lengths that are in accordance with Annex C for the algorithm in question.
Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
Identify the P2PE Assessor who confirms that requirements detailed in Annex A of this document are met where key-establishment protocols using public-key cryptography are used to remotely distribute secret keys:
<Report Findings Here> 6D-2.1 Clear-text secret and private keys and key components must be transferred into an SCD only when it can be ensured that:
Any cameras present in the environment must be positioned to …
Use of public and private key lengths that are in accordance with Annex C for the algorithm in question.
Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
Identify the P2PE Assessor who confirms that requirements detailed in Annex A of this document are met where key-establishment protocols using public-key cryptography are used to remotely distribute secret keys:
<Report Findings Here> 6D-2.1 Clear-text secret and private keys and key components must be transferred into an SCD only when it can be ensured that:
Any cameras present in the environment must be positioned to …
Added
p. 124
- An SCD transfers a plaintext secret or private key only when at least two authorized individuals are identified by the device.
- There is not any mechanism at the interface (including cabling) between the conveyance medium and the SCD that might disclose the transferred keys.
- The SCD is inspected to ensure it has not been subject to any prior tampering, which could lead to the disclosure of clear-text keying material.
<Report Findings Here> 6D-2.2 Only SCDs shall be used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards shall never be used for the loading of clear-text secret or private keys or their components.
6D-2.2 Verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. …
- There is not any mechanism at the interface (including cabling) between the conveyance medium and the SCD that might disclose the transferred keys.
- The SCD is inspected to ensure it has not been subject to any prior tampering, which could lead to the disclosure of clear-text keying material.
<Report Findings Here> 6D-2.2 Only SCDs shall be used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards shall never be used for the loading of clear-text secret or private keys or their components.
6D-2.2 Verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. …
Added
p. 124
Describe how the key-loading processes observed verified that the injection process results in one of the following:
Added
p. 125
6D-2.4 Review documented procedures and observe processes for the use of key-loading devices. Perform the following:
6D-2.4.1 The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
6D-2.4.1 Verify the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or <Report Findings Here> 6D-2.4.2 The key-loading device must be under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
6D-2.4.2 Verify the key-loading device is …
6D-2.4.1 The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
6D-2.4.1 Verify the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or <Report Findings Here> 6D-2.4.2 The key-loading device must be under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it.
6D-2.4.2 Verify the key-loading device is …
Added
p. 126
6D-2.4.4 Verify the key-loading device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred. For example, attempt to output the same value more than one time from the device or cause the device to display check values for its contents both before and after injection and compare.
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that the key-loading device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred:
<Report Findings Here> 6D-2.5 Any media (electronic or otherwise) containing secret or private key components used for loading cryptographic keys must be maintained in a secure location and accessible only to authorized custodian(s). When removed from the secure storage location, media or devices containing key components …
Documented procedures reviewed: <Report Findings Here> Describe how processes for the use of key-loading devices verified that the key-loading device does not retain any information that might disclose the key that was installed in the device or a key that it has successfully transferred:
<Report Findings Here> 6D-2.5 Any media (electronic or otherwise) containing secret or private key components used for loading cryptographic keys must be maintained in a secure location and accessible only to authorized custodian(s). When removed from the secure storage location, media or devices containing key components …
Added
p. 127
Personnel interviewed: <Report Findings Here> Describe how it was verified that if components are in human-readable form, they are visible only to designated component custodians and only for the duration of time required for this person to privately enter the key component into an SCD:
<Report Findings Here> 6D-2.7 Written or printed key component documents must not be opened until immediately prior to use.
6D-2.7.a Review documented procedures and confirm that printed/written key component documents are not opened until immediately prior to use. Documented procedures reviewed: <Report Findings Here> 6D-2.7.b Observe key-loading processes and verify that printed/written key component documents are not opened until immediately prior to use. Describe how the key-loading processes observed verified that printed/written key component documents are not opened until immediately prior to use:
<Report Findings Here> 6D-2.8 A person with access to any component or share of a secret or private key, or to the media conveying this …
<Report Findings Here> 6D-2.7 Written or printed key component documents must not be opened until immediately prior to use.
6D-2.7.a Review documented procedures and confirm that printed/written key component documents are not opened until immediately prior to use. Documented procedures reviewed: <Report Findings Here> 6D-2.7.b Observe key-loading processes and verify that printed/written key component documents are not opened until immediately prior to use. Describe how the key-loading processes observed verified that printed/written key component documents are not opened until immediately prior to use:
<Report Findings Here> 6D-2.8 A person with access to any component or share of a secret or private key, or to the media conveying this …
Added
p. 128
Any hardware used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control.
Any resources (e.g., passwords and associated hardware) used in the key- loading function or for the signing of authenticated applications must be controlled and managed such that no single individual has the capability to enable key loading of clear-text keys or their components.
All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.
All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.
All resources (e.g., passwords and associated hardware) used for key- loading functions and for the signing of authenticated applications are controlled and managed such that no single individual has the …
Any resources (e.g., passwords and associated hardware) used in the key- loading function or for the signing of authenticated applications must be controlled and managed such that no single individual has the capability to enable key loading of clear-text keys or their components.
All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.
All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.
All resources (e.g., passwords and associated hardware) used for key- loading functions and for the signing of authenticated applications are controlled and managed such that no single individual has the …
Added
p. 129
6D-3.4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading or the signing of authenticated applications. Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.
Documented procedures reviewed: <Report Findings Here> 6D-3.4.b Inspect locations and controls for physical tokens to verify that tokens used to enable key loading or the signing of authenticated applications are not in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.
Identify the P2PE Assessor who inspected locations and controls for physical tokens and confirms that tokens used to enable key loading or the signing of authenticated applications are not in the control …
Documented procedures reviewed: <Report Findings Here> 6D-3.4.b Inspect locations and controls for physical tokens to verify that tokens used to enable key loading or the signing of authenticated applications are not in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications under single control.
Identify the P2PE Assessor who inspected locations and controls for physical tokens and confirms that tokens used to enable key loading or the signing of authenticated applications are not in the control …
Added
p. 130
Documented procedures reviewed: <Report Findings Here> 6D-4.1.b Observe the key-loading processes to verify that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians.
Describe how key-loading processes observed verified that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians:
<Report Findings Here> 6D-4.1.c Verify that the methods used for key validation are consistent with ISO 11568•e.g., when check values are used, they should return a value of no more than six hexadecimal characters.
Describe how the key-loading processes observed verified that the methods used for key validation are consistent with ISO 11568:
<Report Findings Here> 6D-4.2 The public key must have its authenticity and integrity ensured. In order to ensure authenticity and integrity, a public key must be …
Describe how key-loading processes observed verified that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and is verified by the applicable key custodians:
<Report Findings Here> 6D-4.1.c Verify that the methods used for key validation are consistent with ISO 11568•e.g., when check values are used, they should return a value of no more than six hexadecimal characters.
Describe how the key-loading processes observed verified that the methods used for key validation are consistent with ISO 11568:
<Report Findings Here> 6D-4.2 The public key must have its authenticity and integrity ensured. In order to ensure authenticity and integrity, a public key must be …
Added
p. 131
6D-5.2 Examine log files and observe logging processes to verify that audit trails are in place for all key-loading events. Log files examined: <Report Findings Here> Describe how the logging processes observed verified that audit trails are in place for all key-loading events:
<Report Findings Here> 6E-1.1 Where two organizations or logically separate systems share a key to encrypt account data (including a key-encipherment key used to encrypt a data- encryption key) communicated between them, that key must:
Be unique to those two entities or logically separate systems and Not be given to any other entity or logically separate systems.
6E-1.1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations or logically separate systems.
For all keys shared between two organizations or logically separate systems for encrypting account data (including key-encryption keys used to encrypt a data- encryption key) perform the …
<Report Findings Here> 6E-1.1 Where two organizations or logically separate systems share a key to encrypt account data (including a key-encipherment key used to encrypt a data- encryption key) communicated between them, that key must:
Be unique to those two entities or logically separate systems and Not be given to any other entity or logically separate systems.
6E-1.1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations or logically separate systems.
For all keys shared between two organizations or logically separate systems for encrypting account data (including key-encryption keys used to encrypt a data- encryption key) perform the …
Added
p. 132
Specific actions that determine whether the legitimate value of the cryptographic key has changed. (For example, encryption of a known value to determine whether the resulting cryptogram matches the expected result.) Proactive safeguards that shut down the source of any synchronization errors and start an investigative process to determine the true cause of the event.
Documented procedures reviewed: <Report Findings Here> 6E-2.2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
Documented procedures reviewed: <Report Findings Here> 6E-2.2.b Interview personnel and observe processes to verify procedures are …
Documented procedures reviewed: <Report Findings Here> 6E-2.2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
Documented procedures reviewed: <Report Findings Here> 6E-2.2.b Interview personnel and observe processes to verify procedures are …
Added
p. 133
For a single purpose•a private key must only be used for either decryption or for creating digital signatures, but not both (except for transaction-originating POI devices).
Private keys must never be used to encrypt other keys.
6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used as follows:
To create digital signatures or to perform decryption operations.
For a single purpose•a private key must only be used for either decryption or for creating digital signatures, but not both.
Private keys are never used to encrypt other keys.
Key-management documentation reviewed: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed: <Report Findings Here> 6E-3.3 Public keys must only be used for a single purpose•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices).
6E-3.3 Examine key-management …
Private keys must never be used to encrypt other keys.
6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only used as follows:
To create digital signatures or to perform decryption operations.
For a single purpose•a private key must only be used for either decryption or for creating digital signatures, but not both.
Private keys are never used to encrypt other keys.
Key-management documentation reviewed: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed: <Report Findings Here> 6E-3.3 Public keys must only be used for a single purpose•a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices).
6E-3.3 Examine key-management …
Added
p. 134
Describe how the compared check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) verified that development and test keys have different key values:
<Report Findings Here> 6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
At all times, the HSMs and servers/computers must be physically and logically secured in accordance with these requirements.
Note this does not apply to HSMs that are never intended to be used for …
<Report Findings Here> 6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
At all times, the HSMs and servers/computers must be physically and logically secured in accordance with these requirements.
Note this does not apply to HSMs that are never intended to be used for …
Added
p. 134
All keying material is deleted from the HSM(s) and the server /computer platforms prior to testing.
Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped and rebuilt from read- only media.
Prior to reuse for production purposes the HSM is returned to factory state.
The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6E-4.1 POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data protection. These keys must be known only in that device and in hardware security modules (HSMs) at the minimum number of facilities consistent with effective system operations.
Disclosure of the key in one such device must not provide any information that could be feasibly used to …
Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped and rebuilt from read- only media.
Prior to reuse for production purposes the HSM is returned to factory state.
The relevant production keying material is restored using the principles of dual control and split knowledge as stated in these requirements.
Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6E-4.1 POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data protection. These keys must be known only in that device and in hardware security modules (HSMs) at the minimum number of facilities consistent with effective system operations.
Disclosure of the key in one such device must not provide any information that could be feasibly used to …
Added
p. 135
Describe how the observed HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POI devices verified that unique keys are generated and used for each POI device:
<Report Findings Here> 6E-4.1.c Examine check values, hash, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI device vendor used) to determine that the associated private keys stored in the POI devices are unique per device•i.e., the public keys are unique.
Describe how the examined check values, hash, or fingerprint values for a sample of cryptographic keys from different POI devices verified that private and secret keys are unique for each POI device:
<Report Findings Here> 6E-4.2 If a POI device directly interfaces with more than one entity …
<Report Findings Here> 6E-4.1.c Examine check values, hash, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI device vendor used) to determine that the associated private keys stored in the POI devices are unique per device•i.e., the public keys are unique.
Describe how the examined check values, hash, or fingerprint values for a sample of cryptographic keys from different POI devices verified that private and secret keys are unique for each POI device:
<Report Findings Here> 6E-4.2 If a POI device directly interfaces with more than one entity …
Added
p. 136
Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.
Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.
Documented procedures reviewed: <Report Findings Here> Describe how the observed processes for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:
<Report Findings Here> 6E-4.3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device. Describe how the processes for generating master keys verified that derivation key4s used to generate keys for multiple devices are never loaded into a POI <Report Findings Here> 6E-4.4 Entities processing or injecting DUKPT or other key-derivation methodologies on behalf of multiple acquiring organizations must incorporate a segmentation strategy in their environments. Segmentation must use one or more of …
Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.
Documented procedures reviewed: <Report Findings Here> Describe how the observed processes for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:
<Report Findings Here> 6E-4.3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device. Describe how the processes for generating master keys verified that derivation key4s used to generate keys for multiple devices are never loaded into a POI <Report Findings Here> 6E-4.4 Entities processing or injecting DUKPT or other key-derivation methodologies on behalf of multiple acquiring organizations must incorporate a segmentation strategy in their environments. Segmentation must use one or more of …
Added
p. 137
Documented procedures reviewed: <Report Findings Here> Describe how the observed key stores verified that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions):
<Report Findings Here> 6F-1.1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions).
Describe how the observed key stores verified that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions):
<Report Findings Here> 6F-1.2 Wherever key components are used, they have the following properties:
6F-1.2 Examine documented procedures and interview responsible personnel to determine all instances where key components …
<Report Findings Here> 6F-1.1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions).
Describe how the observed key stores verified that secret or private keys only exist in one or more approved forms at all times when stored (with the exception of DDKs used on the Host System for hybrid decryption solutions):
<Report Findings Here> 6F-1.2 Wherever key components are used, they have the following properties:
6F-1.2 Examine documented procedures and interview responsible personnel to determine all instances where key components …
Added
p. 138
Describe how the observed key-component access controls and key-custodian authorizations/assignments verified that all individuals with access to key components are designated as key custodians for those particular components:
<Report Findings Here> 6F-1.2.4 Procedures exist to ensure any custodian never has access to sufficient key components or shares to reconstruct a secret or private key cryptographic key.
For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian must not then be assigned component B or C, as this would give them knowledge of two components, which gives them ability to recreate the key.
In an m-of-n scheme where n=5, where three components are required to reconstruct …
<Report Findings Here> 6F-1.2.4 Procedures exist to ensure any custodian never has access to sufficient key components or shares to reconstruct a secret or private key cryptographic key.
For example, in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian must not then be assigned component B or C, as this would give them knowledge of two components, which gives them ability to recreate the key.
In an m-of-n scheme where n=5, where three components are required to reconstruct …
Added
p. 139
<Report Findings Here> 6F-1.3.1.c Ensure clear-text key components do not exist in any other locations, including in non-secure containers, in databases, on floppy disks, or in software programs.
<Report Findings Here> 6F-1.3.1.d Confirm that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear (e.g., at the point in the checklist where the keys are entered).
<Report Findings Here> 6F-1.3.2 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).
Note: Furniture-based locks or containers with a limited set of unique keys
•e.g., desk drawers
•are not sufficient to meet this requirement.
Components for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers.
6F-1.3.2 Inspect each key component storage container and verify the following:
<Report Findings Here> 6F-1.3.1.d Confirm that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear (e.g., at the point in the checklist where the keys are entered).
<Report Findings Here> 6F-1.3.2 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).
Note: Furniture-based locks or containers with a limited set of unique keys
•e.g., desk drawers
•are not sufficient to meet this requirement.
Components for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers.
6F-1.3.2 Inspect each key component storage container and verify the following:
Added
p. 139
<Report Findings Here> 6F-1.3.3 If a key is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner (or designated backup(s)) must have possession of both the token and its access code.
6F-1.3.3 Interview responsible personnel and observe implemented processes to verify that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner•or designated backup(s)•has possession of both the token and its access code.
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner
•or designated backup(s) possession of both the token and its access code:
6F-1.3.3 Interview responsible personnel and observe implemented processes to verify that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner•or designated backup(s)•has possession of both the token and its access code.
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner
•or designated backup(s) possession of both the token and its access code:
Added
p. 140
6F-2.1 Verify documented procedures exist for replacing known or suspected compromised keys that includes all of the following (6F-2.1.1 through 6F-2.1.5 Documented procedures reviewed: <Report Findings Here> 6F-2.1.1 Key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised.
6F-2.1.1 Interview responsible personnel and observe implemented processes to verify key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised.
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised:
<Report Findings Here> 6F-2.1.2 If unauthorized alteration is suspected, new keys …
6F-2.1.1 Interview responsible personnel and observe implemented processes to verify key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised.
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD (or, for hybrid decryption solutions, the Host System) has been compromised:
<Report Findings Here> 6F-2.1.2 If unauthorized alteration is suspected, new keys …
Added
p. 141
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, the following are performed:
<Report Findings Here> 6F-2.1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:
Identification of key personnel A damage assessment including, where necessary, the engagement of outside consultants Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
6F-2.1.4.a Interview responsible personnel and observe implemented processes to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that key personnel are identified and that the escalation process includes notification to organizations that currently share or …
<Report Findings Here> 6F-2.1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including:
Identification of key personnel A damage assessment including, where necessary, the engagement of outside consultants Specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
6F-2.1.4.a Interview responsible personnel and observe implemented processes to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that key personnel are identified and that the escalation process includes notification to organizations that currently share or …
Added
p. 142
Missing secure cryptographic devices Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation Host System tamper-detection mechanism has been activated, for hybrid decryption solutions 6F-2.1.5 Interview responsible personnel and review documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events:
Missing SCDs Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries Tamper-evident seals or authenticable …
Missing SCDs Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries Tamper-evident seals or authenticable …
Added
p. 143
Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key-generation key.
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-3.1.b Observe processes to verify that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge.
Describe how the observed processes verified that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge:
<Report Findings Here> 6F-3.2 An MFK used by host processing systems for encipherment of keys for local storage
•and variants of the MFK
•must not be used …
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-3.1.b Observe processes to verify that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge.
Describe how the observed processes verified that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge:
<Report Findings Here> 6F-3.2 An MFK used by host processing systems for encipherment of keys for local storage
•and variants of the MFK
•must not be used …
Added
p. 144
Such transformations are only used to generate different types of key-encrypting keys from an initial key-encrypting key, or working keys with different purposes from another working key.
Note: Using transforms of keys across different levels of a key hierarchy
•e.g., generating a PEK from a key-encrypting key
•increases the risk of exposure of each of those keys.
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
6F-3.3 Examine documented key-transformation procedures and observe implemented processes to verify that reversible key transformations are not used across different levels of the key hierarchy, as follows:
Variants used as KEKs must …
Note: Using transforms of keys across different levels of a key hierarchy
•e.g., generating a PEK from a key-encrypting key
•increases the risk of exposure of each of those keys.
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
6F-3.3 Examine documented key-transformation procedures and observe implemented processes to verify that reversible key transformations are not used across different levels of the key hierarchy, as follows:
Variants used as KEKs must …
Added
p. 145
Note: Key destruction for keys installed in HSMs and POI devices is addressed in Requirement 6G-3.
6F-4.2.a Examine documented procedures for destroying keys and confirm they are sufficient to ensure that no part of the key or component can be recovered. Documented procedures reviewed: <Report Findings Here> 6F-4.2.b Observe key-destruction processes to verify that no part of the key or component can be recovered. Describe how the key-destruction processes observed verified that no part of the key or component can be recovered:
<Report Findings Here> 6F-4.2.1 Keys on all other storage media types in all permissible forms•physically secured, enciphered (except for electronic database backups of cryptograms), or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder.
6F-4.2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media …
6F-4.2.a Examine documented procedures for destroying keys and confirm they are sufficient to ensure that no part of the key or component can be recovered. Documented procedures reviewed: <Report Findings Here> 6F-4.2.b Observe key-destruction processes to verify that no part of the key or component can be recovered. Describe how the key-destruction processes observed verified that no part of the key or component can be recovered:
<Report Findings Here> 6F-4.2.1 Keys on all other storage media types in all permissible forms•physically secured, enciphered (except for electronic database backups of cryptograms), or components
•must be destroyed following the procedures outlined in ISO
•9564 or ISO
•11568.
For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder.
6F-4.2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media …
Added
p. 146
Describe how the key-conveyance/loading processes observed verified that any key components are destroyed once the keys are successfully loaded and validated as operational:
<Report Findings Here> 6F-5.1 To reduce the opportunity for key compromise, limit the number of key custodians to a minimum required for operational efficiency.
6F-5.1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following: Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed: <Report Findings Here> 6F-5.1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. . Key custodians must be employees or contracted personnel.
6F-5.1.1 Review key-custodian assignments for each component to verify that:
<Report Findings Here> 6F-5.1 To reduce the opportunity for key compromise, limit the number of key custodians to a minimum required for operational efficiency.
6F-5.1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following: Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed: <Report Findings Here> 6F-5.1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. . Key custodians must be employees or contracted personnel.
6F-5.1.1 Review key-custodian assignments for each component to verify that:
Added
p. 146
Describe how the key-custodian assignments reviewed for each component verified that:
<Report Findings Here> 6F-5.1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
6F-5.1.2.a Examine completed key-custodian forms to verify that key custodians sign the form. Completed key-custodian forms reviewed: <Report Findings Here> 6F-5.1.2.b Examine completed key-custodian forms to verify that backup custodians sign the form. Completed key-custodian forms reviewed: <Report Findings Here> 6F-5.1.3 Each key-custodian form provides the following:
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date and time for the custodian’s access Signature of management authorizing the access
<Report Findings Here> 6F-5.1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
6F-5.1.2.a Examine completed key-custodian forms to verify that key custodians sign the form. Completed key-custodian forms reviewed: <Report Findings Here> 6F-5.1.2.b Examine completed key-custodian forms to verify that backup custodians sign the form. Completed key-custodian forms reviewed: <Report Findings Here> 6F-5.1.3 Each key-custodian form provides the following:
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date and time for the custodian’s access Signature of management authorizing the access
Added
p. 147
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date and time for the custodian’s access Signature of management authorizing the access.
Completed key-custodian forms reviewed: <Report Findings Here> 6F-5.1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted below for organizations of insufficient size.
For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to …
Completed key-custodian forms reviewed: <Report Findings Here> 6F-5.1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted below for organizations of insufficient size.
For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to …
Added
p. 148
At a minimum, logs must include the following:
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable) 6F-6.1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
Removed from secure storage Loaded to an SCD Log files reviewed: <Report Findings Here> Describe how log files and audit log settings verified that logs are kept for any time that keys, key components, or related materials are:
Removed from secure storage Loaded to an SCD <Report Findings Here> 6F-6.1.b Review log files and audit log settings to verify that logs include the following:
Date and time in/out Key component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number …
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable) 6F-6.1.a Review log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are:
Removed from secure storage Loaded to an SCD Log files reviewed: <Report Findings Here> Describe how log files and audit log settings verified that logs are kept for any time that keys, key components, or related materials are:
Removed from secure storage Loaded to an SCD <Report Findings Here> 6F-6.1.b Review log files and audit log settings to verify that logs include the following:
Date and time in/out Key component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number …
Added
p. 149
Describe how the backup processes observed verified that backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys:
<Report Findings Here> 6F-7.1.b Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows:
Securely stored with proper access controls Under at least dual control Subject to at least the same level of security control as operational keys as specified in this document Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> OR Describe how backup storage locations verified that backups are maintained as follows:
Securely stored with proper access controls Under at least dual control Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here> 6F-7.2 If backup …
<Report Findings Here> 6F-7.1.b Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows:
Securely stored with proper access controls Under at least dual control Subject to at least the same level of security control as operational keys as specified in this document Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> OR Describe how backup storage locations verified that backups are maintained as follows:
Securely stored with proper access controls Under at least dual control Subject to at least the same level of security control as operational keys as specified in this document <Report Findings Here> 6F-7.2 If backup …
Added
p. 149
6F-7.2 Interview responsible personnel and observe backup processes to verify the following:
The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process All requirements applicable for the original keys also apply to any backup copies of keys and their components.
The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process All requirements applicable for the original keys also apply to any backup copies of keys and their components.
Responsible personnel interviewed: <Report Findings Here> Describe how the backup processes observed verified that:
<Report Findings Here> 6F-8.1 Written procedures must exist and all affected parties must be aware of those procedures. All activities related to key administration must be documented.
This includes all aspects of key administration, as well as:
Security-awareness training Role definition•nominated individual with overall responsibility Background checks for personnel …
The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process All requirements applicable for the original keys also apply to any backup copies of keys and their components.
The creation of any backup copies for top-level keys requires at least two authorized individuals to enable the process All requirements applicable for the original keys also apply to any backup copies of keys and their components.
Responsible personnel interviewed: <Report Findings Here> Describe how the backup processes observed verified that:
<Report Findings Here> 6F-8.1 Written procedures must exist and all affected parties must be aware of those procedures. All activities related to key administration must be documented.
This includes all aspects of key administration, as well as:
Security-awareness training Role definition•nominated individual with overall responsibility Background checks for personnel …
Added
p. 150
Security-awareness training Role definition•nominated individual with overall responsibility Background checks for personnel (within the constraints of local laws) Management of personnel changes, including revocation of access control and other privileges when personnel move Documented procedures reviewed: <Report Findings Here> 6F-8.1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood. Responsible personnel interviewed: <Report Findings Here> 6F-8.1.c Interview personnel to verify that security-awareness training is provided for the appropriate personnel. Personnel interviewed: <Report Findings Here> 6F-8.1.d Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws). Responsible HR personnel interviewed: <Report Findings Here> 6G-1.1 Secure cryptographic devices
•such as HSMs and POI devices
•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior …
•such as HSMs and POI devices
•must be placed into service only if there is assurance that the equipment has not been subjected to unauthorized modifications, substitution, or tampering and has not otherwise been subject to misuse prior …
Added
p. 150
Documented procedures reviewed: <Report Findings Here> 6G-1.1.b Observe processes and interview personnel to verify that processes are followed to provide the following assurances prior to the loading of cryptographic keys:
Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that processes are followed to provide the following assurances prior to the loading of cryptographic keys:
Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that processes are followed to provide the following assurances prior to the loading of cryptographic keys:
Added
p. 151
Controls must include the following:
6G-1.1.1.a Review documented procedures to verify controls are defined to protect POIs, and other SCDs from unauthorized access up to point of deployment.
Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.b Verify that documented procedures include 6G-1.1.1.1 through 6G- 1.1.1.3 below. Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.1 Access to all POI devices, and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
6G-1.1.1.1.a Examine access-control documentation and device configurations to verify that access to all POI devices and key injection/loading devices is defined and documented.
Access-control documentation reviewed: <Report Findings Here> Describe how access-control documentation and device configurations observed verified that access to all POI devices and key injection/loading devices is defined and documented:
<Report Findings Here> 6G-1.1.1.1.b For a sample of POI device types and other SCDs, observe authorized personnel accessing devices and examine access logs to …
6G-1.1.1.a Review documented procedures to verify controls are defined to protect POIs, and other SCDs from unauthorized access up to point of deployment.
Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.b Verify that documented procedures include 6G-1.1.1.1 through 6G- 1.1.1.3 below. Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.1 Access to all POI devices, and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
6G-1.1.1.1.a Examine access-control documentation and device configurations to verify that access to all POI devices and key injection/loading devices is defined and documented.
Access-control documentation reviewed: <Report Findings Here> Describe how access-control documentation and device configurations observed verified that access to all POI devices and key injection/loading devices is defined and documented:
<Report Findings Here> 6G-1.1.1.1.b For a sample of POI device types and other SCDs, observe authorized personnel accessing devices and examine access logs to …
Added
p. 152
Note: “Prior to deployment” for this requirement means prior to the solution provider sending POI devices to either a distribution channel or the end merchant who will use the POI device to process transactions.
6G-1.1.1.3.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment:
All personnel with access to POI devices and other SCDs are documented in a formal list.
All personnel with access to POI devices and other SCDs are authorized by management.
The authorizations are reviewed annually.
Documented authorizations reviewed: <Report Findings Here> 6G-1.1.1.3.b For a sample of POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in the formal list have access to devices.
Sample of POI device types and other SCDs reviewed: <Report Findings Here> Describe how the implemented access controls for the sample of POI device types and other SCDs examined verified that …
6G-1.1.1.3.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment:
All personnel with access to POI devices and other SCDs are documented in a formal list.
All personnel with access to POI devices and other SCDs are authorized by management.
The authorizations are reviewed annually.
Documented authorizations reviewed: <Report Findings Here> 6G-1.1.1.3.b For a sample of POI device types and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in the formal list have access to devices.
Sample of POI device types and other SCDs reviewed: <Report Findings Here> Describe how the implemented access controls for the sample of POI device types and other SCDs examined verified that …
Added
p. 153
Responsible personnel interviewed: <Report Findings Here> 6G-1.4 Dual-control mechanisms must exist to prevent substitution or tampering of HSMs
•both deployed and spare or backup devices
•throughout their lifecycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs, but cannot supplant the implementation of dual-control mechanisms.
6G-1.4.a Examine documented procedures to verify that dual-control mechanisms exist to prevent substitution or tampering of HSMs•both deployed and spare or back-up devices•throughout their life cycle.
Documented procedures reviewed: <Report Findings Here> 6G-1.4.b Interview responsible personnel and physically verify the dual-control mechanism used to prevent substitution or tampering of HSMs•both in service and spare or back-up devices•throughout their life cycle.
Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who physically verified the dual-control mechanism used to prevent substitution or tampering of HSMs• both in service and spare or back-up devices•throughout their life cycle:
<Report …
•both deployed and spare or backup devices
•throughout their lifecycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs, but cannot supplant the implementation of dual-control mechanisms.
6G-1.4.a Examine documented procedures to verify that dual-control mechanisms exist to prevent substitution or tampering of HSMs•both deployed and spare or back-up devices•throughout their life cycle.
Documented procedures reviewed: <Report Findings Here> 6G-1.4.b Interview responsible personnel and physically verify the dual-control mechanism used to prevent substitution or tampering of HSMs•both in service and spare or back-up devices•throughout their life cycle.
Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who physically verified the dual-control mechanism used to prevent substitution or tampering of HSMs• both in service and spare or back-up devices•throughout their life cycle:
<Report …
Added
p. 154
Processes must include:
6G-1.4.4.a Examine documented procedures to verify they require inspection and testing of HSMs prior to installation to verify integrity of device and include requirements specified at 6G-1.4.4.1 through 6G-1.4.4.4 below.
Documented procedures reviewed: <Report Findings Here> 6G-1.4.4.1 Running self-tests to ensure the correct operation of the device.
6G-1.4.4.1 Examine records of device inspections and test results to verify that self-tests are run on devices to ensure the correct operation of the device. Records of device inspections reviewed: <Report Findings Here> Describe how the records of device inspections and test results examined verified that self-tests are run on devices to ensure the correct operation of the <Report Findings Here> 6G-1.4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised.
6G-1.4.4.2 Observe inspection processes and interview responsible personnel to verify that devices are installed, or reinstalled, only after confirming that the device has not been …
6G-1.4.4.a Examine documented procedures to verify they require inspection and testing of HSMs prior to installation to verify integrity of device and include requirements specified at 6G-1.4.4.1 through 6G-1.4.4.4 below.
Documented procedures reviewed: <Report Findings Here> 6G-1.4.4.1 Running self-tests to ensure the correct operation of the device.
6G-1.4.4.1 Examine records of device inspections and test results to verify that self-tests are run on devices to ensure the correct operation of the device. Records of device inspections reviewed: <Report Findings Here> Describe how the records of device inspections and test results examined verified that self-tests are run on devices to ensure the correct operation of the <Report Findings Here> 6G-1.4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised.
6G-1.4.4.2 Observe inspection processes and interview responsible personnel to verify that devices are installed, or reinstalled, only after confirming that the device has not been …
Added
p. 155
6G-1.4.5.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation. Documented procedures reviewed: <Report Findings Here> 6G-1.4.5.b Observe a sample of received devices to verify they are maintained in tamper-evident packaging until ready for installation. Sample of received devices reviewed: <Report Findings Here> 6G-3.1 Procedures are in place to ensure that any SCDs to be removed from service
•e.g., retired or returned for repair
•are not intercepted or used in an unauthorized manner, including that all keys, key material, and account data stored within the device must be rendered irrecoverable.
Note: Without proactive key-removal processes, devices removed from service can retain cryptographic keys in battery-backed RAM for days or weeks. Likewise, host/hardware security modules (HSMs) can also retain keys
•and more critically, the Master File Key
•resident within these devices. Proactive key-removal procedures must be in place to delete all such keys from any SCD being removed …
•e.g., retired or returned for repair
•are not intercepted or used in an unauthorized manner, including that all keys, key material, and account data stored within the device must be rendered irrecoverable.
Note: Without proactive key-removal processes, devices removed from service can retain cryptographic keys in battery-backed RAM for days or weeks. Likewise, host/hardware security modules (HSMs) can also retain keys
•and more critically, the Master File Key
•resident within these devices. Proactive key-removal procedures must be in place to delete all such keys from any SCD being removed …
Added
p. 156
Personnel interviewed: <Report Findings Here> Describe how the demonstration of processes for removing SCDs from service verified that all keying material and account data are rendered irrecoverable, or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data or keys:
<Report Findings Here> 6G-3.1.3 SCDs being decommissioned are tested and inspected to ensure keys and account data have been rendered irrecoverable.
6G-3.1.3 Interview personnel and observe processes for removing SCDs from service to verify that tests and inspections of devices are performed to confirm that keys and account data have been rendered irrecoverable.
Personnel interviewed: <Report Findings Here> Describe how the observed processes for removing SCDs from service verified that tests and inspections of devices are performed to confirm that keys and account data have been rendered irrecoverable:
<Report Findings Here> 6G-3.1.4 Affected entities are notified before devices are returned.
6G-3.1.4 Interview responsible personnel and examine device-return records to …
<Report Findings Here> 6G-3.1.3 SCDs being decommissioned are tested and inspected to ensure keys and account data have been rendered irrecoverable.
6G-3.1.3 Interview personnel and observe processes for removing SCDs from service to verify that tests and inspections of devices are performed to confirm that keys and account data have been rendered irrecoverable.
Personnel interviewed: <Report Findings Here> Describe how the observed processes for removing SCDs from service verified that tests and inspections of devices are performed to confirm that keys and account data have been rendered irrecoverable:
<Report Findings Here> 6G-3.1.4 Affected entities are notified before devices are returned.
6G-3.1.4 Interview responsible personnel and examine device-return records to …
Added
p. 157
Required procedures and processes include the following:
6G-4.1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices.
Documented procedures reviewed: <Report Findings Here> 6G-4.1.b Verify that documented procedures cover requirements 6G-4.1.1 through 6G-4.1.5 below. Documented procedures reviewed: <Report Findings Here> 6G-4.1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords, or for physical access via a physical lock that requires two individuals each with a different high-security key.
For devices that do not support two or more passwords, this may be achieved by …
6G-4.1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices.
Documented procedures reviewed: <Report Findings Here> 6G-4.1.b Verify that documented procedures cover requirements 6G-4.1.1 through 6G-4.1.5 below. Documented procedures reviewed: <Report Findings Here> 6G-4.1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords, or for physical access via a physical lock that requires two individuals each with a different high-security key.
For devices that do not support two or more passwords, this may be achieved by …
Added
p. 158
To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing; To enable application-signing functions; To place the device into a state that allows for the input or output of clear- text key components; For all access to KLDs and authenticated application-signing devices.
To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing; To enable application-signing functions; To place the device into a state that allows for the input or output of clear- text key components; For all access to KLDs and authenticated application-signing devices.
Dual-control mechanisms examined: <Report Findings Here> Describe how the observation of authorized personnel performing the defined activities verified that dual control is implemented for the following:
<Report Findings Here> 6G-4.1.3 Devices must not use default passwords.
6G-4.1.3.a Examine password policies and documented procedures to confirm default passwords must …
To enable any manual key-encryption functions, and any key-encryption functions that occur outside of normal transaction processing; To enable application-signing functions; To place the device into a state that allows for the input or output of clear- text key components; For all access to KLDs and authenticated application-signing devices.
Dual-control mechanisms examined: <Report Findings Here> Describe how the observation of authorized personnel performing the defined activities verified that dual control is implemented for the following:
<Report Findings Here> 6G-4.1.3 Devices must not use default passwords.
6G-4.1.3.a Examine password policies and documented procedures to confirm default passwords must …
Added
p. 159
Responsible personnel interviewed: <Report Findings Here> Describe how devices are at all times within a secure room and either:
Added
p. 159
<Report Findings Here> 6G-5.1 Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed on account-data processing devices before they are placed into service, as well as devices being decommissioned.
6G-5.1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for account-data processing devices placed into service, initialized, deployed, used, and decommissioned Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6G-5.1.b Verify that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.
Documented records reviewed: <Report Findings Here> 6H-1.1 The Data Decryption Keys (DDKs) used in software to decrypt account data must have defined usage limits. This can be achieved through the use of …
6G-5.1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for account-data processing devices placed into service, initialized, deployed, used, and decommissioned Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6G-5.1.b Verify that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.
Documented records reviewed: <Report Findings Here> 6H-1.1 The Data Decryption Keys (DDKs) used in software to decrypt account data must have defined usage limits. This can be achieved through the use of …
Added
p. 160
Each DDK must have a defined usage period (cryptoperiod) based on a formal risk assessment and industry guidance as provided in NIST SP800- 57, ISO TR 14742 and NIST SP800-131. The cryptoperiod defines the duration of time that the DDK may be used to decrypt account data, defined either as a maximum threshold of transactions, or hours, or both (e.g., 1024 transactions or 24 hours, whichever is reached first).
Upon reaching the defined usage threshold, the DDK must not be used for further transaction processing and must be securely erased from memory of the host processing system.
Documented key-management policies and procedures reviewed: <Report Findings Here> 6H-1.1.b Observe the key-management methods used to manage DDKs on the Host System to verify they meet one, or both of the above options. Describe how the key-management methods used to manage DDKs on the Host System meet one, or both, of the above …
Upon reaching the defined usage threshold, the DDK must not be used for further transaction processing and must be securely erased from memory of the host processing system.
Documented key-management policies and procedures reviewed: <Report Findings Here> 6H-1.1.b Observe the key-management methods used to manage DDKs on the Host System to verify they meet one, or both of the above options. Describe how the key-management methods used to manage DDKs on the Host System meet one, or both, of the above …
Added
p. 161
The master key used to generated the DDK must be dedicated to generating DDKs.
Documented key-management policies and procedures reviewed: <Report Findings Here> 6H-1.3.b Observe key-generation processes for generating DDKs from a master key to verify:
A one-way derivation process is used.
A one-way derivation process is used.
The DDK is never generated as a variant of the HSM master file key.
The DDK is never generated as a variant of the HSM master file key.
The master key used to generate the DDK is dedicated to generating DDKs.
The master key used to generate the DDK is dedicated to generating DDKs.
Describe how the key-generation processes observed verified that:
<Report Findings Here> 6H-1.4 The DDK must be encrypted between the HSM and the Host System, e.g., using a fixed transport key or a cryptographic protocol. The method of encryption used must maintain the security policy to which the HSM was approved …
Documented key-management policies and procedures reviewed: <Report Findings Here> 6H-1.3.b Observe key-generation processes for generating DDKs from a master key to verify:
A one-way derivation process is used.
A one-way derivation process is used.
The DDK is never generated as a variant of the HSM master file key.
The DDK is never generated as a variant of the HSM master file key.
The master key used to generate the DDK is dedicated to generating DDKs.
The master key used to generate the DDK is dedicated to generating DDKs.
Describe how the key-generation processes observed verified that:
<Report Findings Here> 6H-1.4 The DDK must be encrypted between the HSM and the Host System, e.g., using a fixed transport key or a cryptographic protocol. The method of encryption used must maintain the security policy to which the HSM was approved …
Added
p. 162
Describe how the key-management processes observed verified that the encryption mechanism used to protect the DDK between the HSM and the Host System uses an encryption key that is equal or greater in strength than the key it protects:
<Report Findings Here> 6H-1.5.2 The encryption key must be unique for each Host System.
6H-1.5.2.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that is unique for each Host System.
Documented key-management policies and procedures reviewed: <Report Findings Here> 6H-1.5.2.b Observe key-management processes to verify that the encryption mechanism uses an encryption key that is unique for each Host System. Describe how the key-management processes observed verified that the encryption mechanism uses an encryption key that is unique for each Host <Report Findings Here> 6H-1.5.3 The encryption key must only be used to encrypt the DDK during transmission between the HSM and the Host System, and …
<Report Findings Here> 6H-1.5.2 The encryption key must be unique for each Host System.
6H-1.5.2.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that is unique for each Host System.
Documented key-management policies and procedures reviewed: <Report Findings Here> 6H-1.5.2.b Observe key-management processes to verify that the encryption mechanism uses an encryption key that is unique for each Host System. Describe how the key-management processes observed verified that the encryption mechanism uses an encryption key that is unique for each Host <Report Findings Here> 6H-1.5.3 The encryption key must only be used to encrypt the DDK during transmission between the HSM and the Host System, and …
Added
p. 163
- Type of key(s) injected
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Note that adding, changing, or removing POI and/or HSM types, or critical key-management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
6I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Note that adding, changing, or removing POI and/or HSM types, or critical key-management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
6I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:
Added
p. 163
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Documented component provider procedures reviewed: <Report Findings Here> Responsible component provider personnel interviewed: <Report Findings Here> 6I-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
Types/models of POIs for which keys have been injected For each type/model of POI:
- Number of POI devices
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Solution provider reports reviewed: <Report Findings Here>
Types/models of POIs for which keys have been injected For each type/model of POI:
- Number of POI devices
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Solution provider reports reviewed: <Report Findings Here>
Added
p. 164
6D Key loading is handled in a secure manner.
6F Keys are administered in a secure manner.
Table 6A.1
• List of symmetric keys (by type) distributed using asymmetric techniques Key type/description:* Purpose/function of the key (including types of devices using key): Description/identifier of asymmetric techniques use for key distribution: Entity performing remote key distribution:
* Note: Must include all keys from Table 6.1 identified as being distributed via remote key distribution techniques.
Domain 6: Normative Annex A, A1 Remote Key Distribution Using Asymmetric Techniques Operations
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 6C-3.2 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed except as noted in the main body of Domain 6 at Requirement 6C-3.1.
6C-3.2 Examine documented procedures to verify that all asymmetric keys used to transmit or convey other cryptographic keys must be (at least) as …
6F Keys are administered in a secure manner.
Table 6A.1
• List of symmetric keys (by type) distributed using asymmetric techniques Key type/description:* Purpose/function of the key (including types of devices using key): Description/identifier of asymmetric techniques use for key distribution: Entity performing remote key distribution:
* Note: Must include all keys from Table 6.1 identified as being distributed via remote key distribution techniques.
Domain 6: Normative Annex A, A1 Remote Key Distribution Using Asymmetric Techniques Operations
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 6C-3.2 All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed except as noted in the main body of Domain 6 at Requirement 6C-3.1.
6C-3.2 Examine documented procedures to verify that all asymmetric keys used to transmit or convey other cryptographic keys must be (at least) as …
Added
p. 166
POI devices validate authentication credentials of KDHs immediately prior to any key transport, exchange, or establishment with that device.
KDHs validate authentication credentials of POIs immediately prior to any key transport, exchange, or establishment with that device.
Applicable personnel interviewed: <Report Findings Here> 6D-4.4 Key-establishment and distribution procedures must be designed such that:
Within an implementation design, there shall be no means available for “man-in-the-middle” attacks•e.g., through binding of the KDH certificate upon the initial communication.
System implementations must be designed and implemented to prevent replay attacks•e.g., through the use of random nonces.
6D-4.4 Examine system and process documentation to verify that key- establishment and distribution procedures are designed such that:
There are no means available in the implementation design for “man-in- the-middle” attacks.
System implementations are designed to prevent replay attacks.
System and process documentation reviewed: <Report Findings Here> 6D-4.5 Key pairs generated external to the device that uses the key …
KDHs validate authentication credentials of POIs immediately prior to any key transport, exchange, or establishment with that device.
Applicable personnel interviewed: <Report Findings Here> 6D-4.4 Key-establishment and distribution procedures must be designed such that:
Within an implementation design, there shall be no means available for “man-in-the-middle” attacks•e.g., through binding of the KDH certificate upon the initial communication.
System implementations must be designed and implemented to prevent replay attacks•e.g., through the use of random nonces.
6D-4.4 Examine system and process documentation to verify that key- establishment and distribution procedures are designed such that:
There are no means available in the implementation design for “man-in- the-middle” attacks.
System implementations are designed to prevent replay attacks.
System and process documentation reviewed: <Report Findings Here> 6D-4.5 Key pairs generated external to the device that uses the key …
Added
p. 168
Responsible personnel interviewed: <Report Findings Here> Describe how the observed certificate issuing and replacement processes verified that:
<Report Findings Here> 6E-3.7 KDH private keys must not be shared between devices except for load balancing and disaster recovery.
6E-3.7 Examine documented processes to verify that KDH private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.
6E-3.8.a Examine documented processes to verify that POI private keys are not permitted to be shared between devices. Documented processes reviewed: <Report Findings Here> 6E-3.8.b Inspect public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI. Describe how public key certificates on the host processing system confirmed that a unique certificate exists for each connected POI:
<Report Findings Here> 6F-1.4 Private keys used to sign certificates, certificate status lists, messages, or for key protection must exist only in one or more of the …
<Report Findings Here> 6E-3.7 KDH private keys must not be shared between devices except for load balancing and disaster recovery.
6E-3.7 Examine documented processes to verify that KDH private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.
6E-3.8.a Examine documented processes to verify that POI private keys are not permitted to be shared between devices. Documented processes reviewed: <Report Findings Here> 6E-3.8.b Inspect public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI. Describe how public key certificates on the host processing system confirmed that a unique certificate exists for each connected POI:
<Report Findings Here> 6F-1.4 Private keys used to sign certificates, certificate status lists, messages, or for key protection must exist only in one or more of the …
Added
p. 171
6F-8 Documented procedures must exist and must be demonstrably in use for all key-administration operations.
6D Key loading is handled in a secure manner.
6F Keys are administered in a secure manner.
6D Key loading is handled in a secure manner.
6F Keys are administered in a secure manner.
Added
p. 171
6G Equipment used to process account data and keys is managed in a secure manner.
6G-3 Procedures must be in place and implemented to protect and SCDs•and endure the destruction of any cryptographic keys or key material within such devices•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.
<Report Findings Here> 6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
At all times, the HSMs and servers/computers must be physically and logically secured in accordance …
6G-3 Procedures must be in place and implemented to protect and SCDs•and endure the destruction of any cryptographic keys or key material within such devices•when removed from service, retired at the end of the deployment lifecycle, or returned for repair.
<Report Findings Here> 6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
At all times, the HSMs and servers/computers must be physically and logically secured in accordance …
Added
p. 172
<Report Findings Here> 6D-4.6 Key pairs generated external to the device that uses the key pair must be securely transferred and loaded into the device and must provide for key protection in accordance with this document. That is, the secrecy of the private key and the integrity of the public key must be ensured. The process must ensure that once keys are injected they are no longer available for injection into other POI devices•i.e., key pairs are unique per POI device.
Documented procedures reviewed: <Report Findings Here> Describe how key transfer and loading operations verified that the secrecy of private keys and the integrity of the public keys are ensured <Report Findings Here> Describe how key transfer and loading operations verified that the process ensures that key pairs are unique per POI device:
Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped …
Documented procedures reviewed: <Report Findings Here> Describe how key transfer and loading operations verified that the secrecy of private keys and the integrity of the public keys are ensured <Report Findings Here> Describe how key transfer and loading operations verified that the process ensures that key pairs are unique per POI device:
Subsequent to completion of testing, all keying materials must be deleted and the server/computer platforms must be wiped …
Added
p. 173
All keying material is deleted from the HSM(s) and the server/computer platforms prior to testing.
Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6E-3.6 Key pairs must not be reused for certificate renewal or replacement•i.e., new key pairs must be generated.
New certificate issue request Certificate replacement request Each key pair generated results in only one certificate Documented procedures reviewed: <Report Findings Here> 6E-3.6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:
<Report Findings Here> 6E-3.9 Mechanisms must be utilized to preclude the use of a key for other than its designated and intended purpose
•that is, keys must be used in accordance with their certificate policy. See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.
6E-3.9.a Examine key-usage documentation and ensure that the usage is in accordance with the certificate policy. Key-usage …
Personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6E-3.6 Key pairs must not be reused for certificate renewal or replacement•i.e., new key pairs must be generated.
New certificate issue request Certificate replacement request Each key pair generated results in only one certificate Documented procedures reviewed: <Report Findings Here> 6E-3.6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that:
<Report Findings Here> 6E-3.9 Mechanisms must be utilized to preclude the use of a key for other than its designated and intended purpose
•that is, keys must be used in accordance with their certificate policy. See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.
6E-3.9.a Examine key-usage documentation and ensure that the usage is in accordance with the certificate policy. Key-usage …
Added
p. 174
Vendor documentation reviewed: <Report Findings Here> Describe how the vendor documentation and device configuration settings observed verified that the device mechanisms are implemented that preclude the use of a key for other than its designated and intended purpose:
<Report Findings Here> 6E-3.9.1 CA certificate signature keys, certificate (entity) status checking (e.g., Certificate Revocation Lists) signature keys, or signature keys for updating valid/authorized host lists in encryption devices must not be used for any purpose other than subordinate entity certificate requests, certificate status checking, and self-signed root certificates.
Note: The keys used for certificate signing and certificate (entity) status checking (and if applicable, self-signed roots) may be for combined usage or may exist as separate keys dedicated to either certificate-signing or certificate (entity) status checking.
6E-3.9.1.a Examine certificate policy and documented procedures to verify that:
Certificate signature keys, Certificate status checking (e.g., Certificate Revocation Lists) signature Signature keys for updating valid/authorized host …
<Report Findings Here> 6E-3.9.1 CA certificate signature keys, certificate (entity) status checking (e.g., Certificate Revocation Lists) signature keys, or signature keys for updating valid/authorized host lists in encryption devices must not be used for any purpose other than subordinate entity certificate requests, certificate status checking, and self-signed root certificates.
Note: The keys used for certificate signing and certificate (entity) status checking (and if applicable, self-signed roots) may be for combined usage or may exist as separate keys dedicated to either certificate-signing or certificate (entity) status checking.
6E-3.9.1.a Examine certificate policy and documented procedures to verify that:
Certificate signature keys, Certificate status checking (e.g., Certificate Revocation Lists) signature Signature keys for updating valid/authorized host …
Added
p. 174
Certificate policy and documented procedures reviewed: <Report Findings Here> 6E-3.9.1.b Interview responsible personnel and observe demonstration to verify Certificate signature keys, Status checking (e.g., Certificate Revocation Lists) signature keys, or Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:
Responsible personnel interviewed: <Report Findings Here> Describe how the demonstration verified that:
Certificate signature keys, Status checking (e.g., Certificate Revocation Lists) signature keys, or Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:
<Report Findings Here> 6E-3.9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs.
6E-3.9.2 If a CA issues certificates to other CAs, examine the CA certificate policy and documented procedures to verify that the CA does not also issue certificates to POI devices.
CA certificate policy and documented procedures reviewed: <Report Findings Here>
Within …
Responsible personnel interviewed: <Report Findings Here> Describe how the demonstration verified that:
Certificate signature keys, Status checking (e.g., Certificate Revocation Lists) signature keys, or Signature keys for updating valid/authorized host lists in POIs Are not used for any purpose other than:
<Report Findings Here> 6E-3.9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs.
6E-3.9.2 If a CA issues certificates to other CAs, examine the CA certificate policy and documented procedures to verify that the CA does not also issue certificates to POI devices.
CA certificate policy and documented procedures reviewed: <Report Findings Here>
Within …
Added
p. 175
6E-3.10 Examine documented procedures to verify that mechanisms are defined for restricting and controlling the use of public and private keys such that they can only be used for their intended purpose.
Documented procedures reviewed: <Report Findings Here> 6E-3.11 CA private keys must not be shared between devices except for load balancing and disaster recovery.
6E-3.11 Examine CA’s documented processes to verify that CA private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.
CA’s documented processes reviewed: <Report Findings Here> 6E-3.12 The PKI used for remote key distribution must not be used for any other purpose, e.g., cannot be used for firmware or application authentication.
6E-3.12.a Interview responsible personnel to verify that the PKI is operated solely for the purposes of remote key distribution: Responsible personnel interviewed: <Report Findings Here> 6E-3.12.b Examine the documented certificate policy to verify that the CA is operated solely for the …
Documented procedures reviewed: <Report Findings Here> 6E-3.11 CA private keys must not be shared between devices except for load balancing and disaster recovery.
6E-3.11 Examine CA’s documented processes to verify that CA private keys are not permitted to be shared between devices, except for load balancing and disaster recovery.
CA’s documented processes reviewed: <Report Findings Here> 6E-3.12 The PKI used for remote key distribution must not be used for any other purpose, e.g., cannot be used for firmware or application authentication.
6E-3.12.a Interview responsible personnel to verify that the PKI is operated solely for the purposes of remote key distribution: Responsible personnel interviewed: <Report Findings Here> 6E-3.12.b Examine the documented certificate policy to verify that the CA is operated solely for the …
Added
p. 176
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> Describe the observations that confirmed that Root CAs provide for segmentation of risk to address key compromise:
<Report Findings Here> 6F-2.7 Mechanisms must be in place to respond to address compromise of a CA due to, for example, key compromise or mismanagement. This must include procedures to revoke or otherwise invalidate the usage of subordinate certificates, and notification of affected entities.
6F-2.7.a Examine documented procedures to verify that mechanisms are defined to respond to compromise of a CA. Verify the mechanisms include procedures to:
Revoke subordinate certificates, and Notify affected entities.
Revoke subordinate certificates, and Notify affected entities.
Responsible personnel interviewed: <Report Findings Here> 6F-2.7.1 The CA must cease issuance of certificates if a compromise is known or suspected and perform a damage assessment, including a documented analysis of how and why the event occurred.
6F-2.7.1.a Examine documented procedures to verify …
<Report Findings Here> 6F-2.7 Mechanisms must be in place to respond to address compromise of a CA due to, for example, key compromise or mismanagement. This must include procedures to revoke or otherwise invalidate the usage of subordinate certificates, and notification of affected entities.
6F-2.7.a Examine documented procedures to verify that mechanisms are defined to respond to compromise of a CA. Verify the mechanisms include procedures to:
Revoke subordinate certificates, and Notify affected entities.
Revoke subordinate certificates, and Notify affected entities.
Responsible personnel interviewed: <Report Findings Here> 6F-2.7.1 The CA must cease issuance of certificates if a compromise is known or suspected and perform a damage assessment, including a documented analysis of how and why the event occurred.
6F-2.7.1.a Examine documented procedures to verify …
Added
p. 176
The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
Responsible personnel interviewed: <Report Findings Here> Describe how the observed process verified that in the event a compromise is known or suspected:
The CA will perform a damage assessment, including a documented analysis of how and why the event occurred <Report Findings Here> 6F-2.7.2 In the event of confirming a compromise, the CA must determine whether to revoke and reissue all signed certificates with a newly generated signing key.
The CA will perform a damage assessment, including a documented analysis of how and why the event occurred.
Responsible personnel interviewed: <Report Findings Here> Describe how the observed process verified that in the event a compromise is known or suspected:
The CA will perform a damage assessment, including a documented analysis of how and why the event occurred <Report Findings Here> 6F-2.7.2 In the event of confirming a compromise, the CA must determine whether to revoke and reissue all signed certificates with a newly generated signing key.
Added
p. 177
Documented procedures reviewed: <Report Findings Here> 6F-2.7.2.b Interview responsible personnel to verify procedures are followed for the CA to determine whether to revoke and reissue all signed certificates with a newly generated signing key.
Responsible personnel interviewed: <Report Findings Here> 6F-2.7.3 Mechanisms (e.g., time stamping) must exist to prevent the usage of fraudulent certificates, once identified.
6F-2.7.3.a Examine documented procedures to verify that mechanisms are defined to prevent the usage of fraudulent certificates. Documented procedures reviewed: <Report Findings Here> 6F-2.7.3.b Interview responsible personnel and observe implemented mechanisms to verify the prevention of the use of fraudulent certificates Responsible personnel interviewed: <Report Findings Here> Describe how the implemented mechanisms observed verified the prevention of the use of fraudulent certificates:
<Report Findings Here> 6F-2.7.4 The compromised CA must notify any superior or subordinate CAs of the compromise. The compromise damage analysis must include a determination of whether subordinate CAs and KDHs must have their certificates …
Responsible personnel interviewed: <Report Findings Here> 6F-2.7.3 Mechanisms (e.g., time stamping) must exist to prevent the usage of fraudulent certificates, once identified.
6F-2.7.3.a Examine documented procedures to verify that mechanisms are defined to prevent the usage of fraudulent certificates. Documented procedures reviewed: <Report Findings Here> 6F-2.7.3.b Interview responsible personnel and observe implemented mechanisms to verify the prevention of the use of fraudulent certificates Responsible personnel interviewed: <Report Findings Here> Describe how the implemented mechanisms observed verified the prevention of the use of fraudulent certificates:
<Report Findings Here> 6F-2.7.4 The compromised CA must notify any superior or subordinate CAs of the compromise. The compromise damage analysis must include a determination of whether subordinate CAs and KDHs must have their certificates …
Added
p. 179
6F-5.3.1 CA systems that issue certificates to other CAs and KDHs must be operated offline using a dedicated closed network (not a network segment).
The network must only be used for certificate issuance and/or revocation.
Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
6F-5.3.1 Examine network diagrams and observe network and system configurations to verify:
CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).
CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).
The network is only used for certificate issuance, revocation, or both certificate issuance and revocation.
The network is only used for certificate issuance, revocation, …
The network must only be used for certificate issuance and/or revocation.
Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
Outside network access shall exist only for the purposes of “pushing” certificate-status information to relying parties (e.g., KDHs).
6F-5.3.1 Examine network diagrams and observe network and system configurations to verify:
CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).
CA systems that issue certificates to other CAs and KDHs are operated offline using a dedicated closed network (not a network segment).
The network is only used for certificate issuance, revocation, or both certificate issuance and revocation.
The network is only used for certificate issuance, revocation, …
Added
p. 180
Describe how observation of the authorized CA personnel’s attempted non- console access to the host platform using valid CA credentials without using an authenticated encrypted session verified that non-console access is not permitted:
<Report Findings Here> 6F-5.3.5 CA certificate (for POI/KDH authentication and validity status checking) signing keys must only be enabled under at least dual control.
Note: Certificate requests may be vetted (approved) using single user logical access to the RA application.
6F-5.3.5.a Examine the certificate security policy and certification practice statement to verify that CA certificate-signing keys must only be enabled under at least dual control.
Documented certificate security policy and certification practice statement <Report Findings Here> 6F-5.3.5.b Observe certificate-signing processes to verify that signing keys are enabled only under at least dual control. Describe how the certificate-signing processes observed verified that signing keys are enabled only under at least dual control:
<Report Findings Here> 6F-5.4 The CA shall require a separation of …
<Report Findings Here> 6F-5.3.5 CA certificate (for POI/KDH authentication and validity status checking) signing keys must only be enabled under at least dual control.
Note: Certificate requests may be vetted (approved) using single user logical access to the RA application.
6F-5.3.5.a Examine the certificate security policy and certification practice statement to verify that CA certificate-signing keys must only be enabled under at least dual control.
Documented certificate security policy and certification practice statement <Report Findings Here> 6F-5.3.5.b Observe certificate-signing processes to verify that signing keys are enabled only under at least dual control. Describe how the certificate-signing processes observed verified that signing keys are enabled only under at least dual control:
<Report Findings Here> 6F-5.4 The CA shall require a separation of …
Added
p. 182
6F-5.5.2.a Examine documented procedures to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the network.
Documented procedures reviewed: <Report Findings Here> 6F-5.5.2.b Examine system configurations and interview responsible personnel to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the network.
Responsible personnel interviewed: <Report Findings Here> Describe how the system configurations observed verified that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the <Report Findings Here> 6F-5.6 Audit trails must include but not be limited to the following:
All key-management operations, such as key generation, loading, transmission, backup, recovery, compromise, and …
Documented procedures reviewed: <Report Findings Here> 6F-5.5.2.b Examine system configurations and interview responsible personnel to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the network.
Responsible personnel interviewed: <Report Findings Here> Describe how the system configurations observed verified that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the <Report Findings Here> 6F-5.6 Audit trails must include but not be limited to the following:
All key-management operations, such as key generation, loading, transmission, backup, recovery, compromise, and …
Added
p. 183
<Report Findings Here> 6F-5.6.2 Records pertaining to certificate issuance and revocation must, at a minimum, be retained for the life of the associated certificate.
6F-5.6.2.a For a sample of certificate issuances, examine audit records to verify that the records are retained for at least the life of the associated certificate. Sample of certificate issuances reviewed: <Report Findings Here> Audit records examined: <Report Findings Here> 6F-5.6.2.b For a sample of certificate revocations, examine audit records to verify that the records are retained for at least the life of the associated certificate.
Sample of certificate revocations reviewed: <Report Findings Here> Audit records examined: <Report Findings Here> 6F-5.6.3 Logical events are divided into operating-system and CA application events. For both, the following must be recorded in the form of an audit record:
6F-5.6.2.a For a sample of certificate issuances, examine audit records to verify that the records are retained for at least the life of the associated certificate. Sample of certificate issuances reviewed: <Report Findings Here> Audit records examined: <Report Findings Here> 6F-5.6.2.b For a sample of certificate revocations, examine audit records to verify that the records are retained for at least the life of the associated certificate.
Sample of certificate revocations reviewed: <Report Findings Here> Audit records examined: <Report Findings Here> 6F-5.6.3 Logical events are divided into operating-system and CA application events. For both, the following must be recorded in the form of an audit record:
Added
p. 183
6F-5.6.3.a Examine audit trails to verify that logical events are divided into operating-system and CA application events. Describe how the examined audit trails verified that logical events are divided into operating system and CA application events:
<Report Findings Here> 6F-6.3.b Examine a sample of operating-system logs to verify they contain the following information:
Sample of operating-system logs reviewed: <Report Findings Here> 6F-5.6.3.c Examine a sample of application logs to verify they contain the following information:
Sample of application logs reviewed: <Report Findings Here>
<Report Findings Here> 6F-6.3.b Examine a sample of operating-system logs to verify they contain the following information:
Sample of operating-system logs reviewed: <Report Findings Here> 6F-5.6.3.c Examine a sample of application logs to verify they contain the following information:
Sample of application logs reviewed: <Report Findings Here>
Added
p. 184
• Requirements for message authentication using symmetric techniques) mechanism for detection of alteration.
• Requirements for message authentication using symmetric techniques) mechanism for detection of alteration.
The signing/MACing key(s) used for this must be protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
6F-5.7.a Examine log security controls to verify that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in
Describe how log security controls verified that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in ISO
• Requirements for message authentication using symmetric techniques) mechanism for detection of alteration:
<Report Findings Here> 6F-5.7.b Review documentation and interview personnel and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
Documentation reviewed: <Report Findings …
• Requirements for message authentication using symmetric techniques) mechanism for detection of alteration.
The signing/MACing key(s) used for this must be protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
6F-5.7.a Examine log security controls to verify that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in
Describe how log security controls verified that CA application logs use a digital signature or a symmetric MAC (based on one of the methods stated in ISO
• Requirements for message authentication using symmetric techniques) mechanism for detection of alteration:
<Report Findings Here> 6F-5.7.b Review documentation and interview personnel and observe to verify that signing/MACing key(s) used for this are protected using a secure cryptographic device in accordance with the key-management requirements stipulated in this document.
Documentation reviewed: <Report Findings …
Added
p. 184
6F-5.7.1.a Examine network and system configurations to verify that certificate- processing system components operated online are protected from unauthorized access by firewall(s).
Describe how the observed network and system configurations verified that certificate-processing system components operated online are protected from unauthorized access by firewall(s):
Deny all services not explicitly permitted.
Describe how the observed firewall configurations verified they are configured Deny all services not explicitly permitted.
<Report Findings Here> 6F-5.7.2 Online certificate-processing systems must employ individually or in combination network and host-based intrusion detection systems (IDS) to detect inappropriate access. At a minimum, database servers and the application servers for RA and web, as well as the intervening segments, must be covered.
6F-5.7.2.a Observe network-based and/or host-based IDS configurations to verify that on-line certificate-processing systems are protected by IDS to detect inappropriate access.
Describe how the observed network-based and/or host-based IDS configurations verified that on-line certificate-processing systems are protected by IDS to detect inappropriate …
Describe how the observed network and system configurations verified that certificate-processing system components operated online are protected from unauthorized access by firewall(s):
Deny all services not explicitly permitted.
Describe how the observed firewall configurations verified they are configured Deny all services not explicitly permitted.
<Report Findings Here> 6F-5.7.2 Online certificate-processing systems must employ individually or in combination network and host-based intrusion detection systems (IDS) to detect inappropriate access. At a minimum, database servers and the application servers for RA and web, as well as the intervening segments, must be covered.
6F-5.7.2.a Observe network-based and/or host-based IDS configurations to verify that on-line certificate-processing systems are protected by IDS to detect inappropriate access.
Describe how the observed network-based and/or host-based IDS configurations verified that on-line certificate-processing systems are protected by IDS to detect inappropriate …
Added
p. 187
Sample of system components reviewed: <Report Findings Here> Describe how the observed system configuration settings verified that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts:
<Report Findings Here> 6F-5.8.6 Authentication parameters must require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months.
6F-5.8.6 For a sample of system components, obtain and inspect system configuration settings to verify that authentication parameters are set to require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months.
Sample of system components reviewed: <Report Findings Here> Describe how the observed system configuration settings verified that authentication parameters are set to require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months:
<Report Findings Here> 6F-5.8.7 Passwords are not stored on any of the systems except in …
<Report Findings Here> 6F-5.8.6 Authentication parameters must require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months.
6F-5.8.6 For a sample of system components, obtain and inspect system configuration settings to verify that authentication parameters are set to require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months.
Sample of system components reviewed: <Report Findings Here> Describe how the observed system configuration settings verified that authentication parameters are set to require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months:
<Report Findings Here> 6F-5.8.7 Passwords are not stored on any of the systems except in …
Added
p. 188
Describe how the observed devices in use verified that the security tokens have an associated usage-authentication mechanism, such as a biometric or associated PIN/passphrase to enable their usage:
<Report Findings Here> 6F-5.8.9.b Examine token-configuration settings to verify parameters are set to require PINs/passwords be at least eight decimal digits in length, or equivalent. Describe how the observed token-configuration settings verified that parameters are set to require PINs/passwords be at least eight decimal digits in length, or equivalent:
<Report Findings Here> 6F-5.9 Implement a method to synchronize all critical system clocks and times for all systems involved in key-management operations.
6F-5.9.a Examine documented procedures and system configuration standards to verify a method is defined to synchronize all critical system clocks and times for all systems involved in key-management operations.
Documented procedures and system configuration standards reviewed: <Report Findings Here> 6F-5.9.b For a sample of critical systems, review the time-related system parameters to verify that system …
<Report Findings Here> 6F-5.8.9.b Examine token-configuration settings to verify parameters are set to require PINs/passwords be at least eight decimal digits in length, or equivalent. Describe how the observed token-configuration settings verified that parameters are set to require PINs/passwords be at least eight decimal digits in length, or equivalent:
<Report Findings Here> 6F-5.9 Implement a method to synchronize all critical system clocks and times for all systems involved in key-management operations.
6F-5.9.a Examine documented procedures and system configuration standards to verify a method is defined to synchronize all critical system clocks and times for all systems involved in key-management operations.
Documented procedures and system configuration standards reviewed: <Report Findings Here> 6F-5.9.b For a sample of critical systems, review the time-related system parameters to verify that system …
Added
p. 189
Describe how the observed system and network configurations and physical access controls verified that all physical and logical CA system components are separated from key-distribution systems:
<Report Findings Here> 6F-8.3 Each CA operator must develop a certification practice statement (CPS). (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.) The CPS must be consistent with the requirements described within this document.
The CA shall operate in accordance with its CPS.
Note: This may take the form of a declaration by the CA operator of the details of its trustworthy system and the practices it employs in its operations and in support of the issuance of certificates. A CPS may take the form of either a specific, single document or a collection of specific documents.
The CPS must be consistent with the requirements described within this document. The CA shall operate in accordance …
<Report Findings Here> 6F-8.3 Each CA operator must develop a certification practice statement (CPS). (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.) The CPS must be consistent with the requirements described within this document.
The CA shall operate in accordance with its CPS.
Note: This may take the form of a declaration by the CA operator of the details of its trustworthy system and the practices it employs in its operations and in support of the issuance of certificates. A CPS may take the form of either a specific, single document or a collection of specific documents.
The CPS must be consistent with the requirements described within this document. The CA shall operate in accordance …
Added
p. 190
Verification of the certificate applicant’s possession of the associated private key through the use of a digitally signed certificate request pursuant to PKCS #10 or another cryptographically-equivalent demonstration; Determination that the organization exists by using at least one third-party identity-proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization; Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant to confirm that the organization has authorized the certificate application, confirmation of the employment of the representative submitting the certificate application on behalf of the certificate applicant, and confirmation of the authority of the representative to act on behalf of the certificate applicant; Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant’s representative to confirm that the person named as representative has submitted …
Added
p. 190
6F-8.5.1.a Examine documented procedures to verify that certificate-signing requests, including certificate or key-validity status changes, require validation The entity submitting the request is who it claims to be.
The entity submitting the request is who it claims to be.
The entity submitting the request is who it claims to be.
Added
p. 191
Certificate-signing requests reviewed: <Report Findings Here> 6F-8.5.2 RAs must retain documentation and audit trails relating to the identification of entities for all certificates issued and certificates whose status had changed for the life of the associated certificates.
6F-8.5.2 Examine documentation and audit trails to verify that the identification of entities is retained for the life of the associated certificates:
For all certificates issued For all certificates whose status had changed Documentation reviewed: <Report Findings Here> Describe how the observation of audit trails verified that the identification of entities is retained for the life of the associated certificates:
For all certificates issued For all certificates whose status had changed <Report Findings Here> 6G-3.2.1 The certificate-processing operations center must implement a three-tier physical security boundary, as follows:
Level One Barrier
• Consists of the entrance to the facility.
Level Two Barrier
• Secures the entrance beyond the foyer/reception area to the CA facility.
…
6F-8.5.2 Examine documentation and audit trails to verify that the identification of entities is retained for the life of the associated certificates:
For all certificates issued For all certificates whose status had changed Documentation reviewed: <Report Findings Here> Describe how the observation of audit trails verified that the identification of entities is retained for the life of the associated certificates:
For all certificates issued For all certificates whose status had changed <Report Findings Here> 6G-3.2.1 The certificate-processing operations center must implement a three-tier physical security boundary, as follows:
Level One Barrier
• Consists of the entrance to the facility.
Level Two Barrier
• Secures the entrance beyond the foyer/reception area to the CA facility.
…
Added
p. 192
Level One Barrier
• The entrance to the facility Level Two Barrier
• The entrance beyond the foyer/reception area to the CA facility Level Three Barrier
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Describe how the physical facility observed verified that three tiers of physical security are implemented as follows:
Level One Barrier
• The entrance to the facility Level Two Barrier
• The entrance beyond the foyer/reception area to the CA facility Level Three Barrier
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices <Report Findings Here> Level 1 Barrier 6G-3.2.2 The entrance to the CA facility/building must include the following controls:
6G-3.2.2.1 The facility entrance only allows authorized personnel to enter the facility.
6G-3.2.2.1.a Examine physical-security procedures and policies to verify they require that the facility entrance …
• The entrance to the facility Level Two Barrier
• The entrance beyond the foyer/reception area to the CA facility Level Three Barrier
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Describe how the physical facility observed verified that three tiers of physical security are implemented as follows:
Level One Barrier
• The entrance to the facility Level Two Barrier
• The entrance beyond the foyer/reception area to the CA facility Level Three Barrier
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices <Report Findings Here> Level 1 Barrier 6G-3.2.2 The entrance to the CA facility/building must include the following controls:
6G-3.2.2.1 The facility entrance only allows authorized personnel to enter the facility.
6G-3.2.2.1.a Examine physical-security procedures and policies to verify they require that the facility entrance …
Added
p. 193
6G-3.2.3.a Examine physical-security procedures and policies to verify that only authorized personnel are allowed beyond the Level 2 barrier/entrance. Documented physical-security procedures and policies reviewed: <Report Findings Here> 6G-3.2.3.b Observe personnel entering the Level 2 barrier/entrance to verify that only authorized personnel are allowed through. Identify the P2PE Assessor who confirms that only authorized personnel are allowed to enter through the Level 2 barrier/entrance:
<Report Findings Here> 6G-3.2.3.1 Visitors must be authorized and escorted at all times within the Level 2 environment.
6G-3.2.3.1.a Examine documented policies and procedures to verify that authorized visitors must be escorted at all times within the Level 2 environment. Documented physical-security procedures and policies reviewed: <Report Findings Here> 6G-3.2.3.1.b Interview personnel and observe visitors entering the environment to verify that visitors are authorized and escorted at all times within the Level 2 environment.
Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that visitors entering the …
<Report Findings Here> 6G-3.2.3.1 Visitors must be authorized and escorted at all times within the Level 2 environment.
6G-3.2.3.1.a Examine documented policies and procedures to verify that authorized visitors must be escorted at all times within the Level 2 environment. Documented physical-security procedures and policies reviewed: <Report Findings Here> 6G-3.2.3.1.b Interview personnel and observe visitors entering the environment to verify that visitors are authorized and escorted at all times within the Level 2 environment.
Personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that visitors entering the …
Added
p. 194
<Report Findings Here> 6G-3.2.5.c Observe operations and interview personnel to confirm that the Level 3 secure room is not used for any business activity other than certificate operations.
<Report Findings Here> 6G-3.2.5.1 Doors to the Level 3 area must have locking mechanisms.
6G-3.2.5.1 Observe Level 3 environment entrances to verify that all doors to the Level 3 environment have locking mechanisms. Identify the P2PE Assessor who confirms that all doors to the Level 3 environment have locking mechanisms:
<Report Findings Here> 6G-3.2.5.2 The Level 3 environment must be enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to- slab) walls, steel mesh, or bars.
For example, the Level 3 environment may be implemented within a “caged” environment.
6G-3.2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as have …
<Report Findings Here> 6G-3.2.5.1 Doors to the Level 3 area must have locking mechanisms.
6G-3.2.5.1 Observe Level 3 environment entrances to verify that all doors to the Level 3 environment have locking mechanisms. Identify the P2PE Assessor who confirms that all doors to the Level 3 environment have locking mechanisms:
<Report Findings Here> 6G-3.2.5.2 The Level 3 environment must be enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to- slab) walls, steel mesh, or bars.
For example, the Level 3 environment may be implemented within a “caged” environment.
6G-3.2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as have …
Added
p. 196
Documented policies and procedures reviewed: <Report Findings Here> 6G-3.2.7.b Observe authorized personnel accessing the Level 3 environment to verify that dual-control access and dual-occupancy is enforced such that the room is never occupied by one person alone for more than thirty (30) seconds.
Describe how the observation of authorized personnel accessing the Level 3 environment verified that dual-control access and dual-occupancy is enforced such that the room is never occupied by one person alone for more than thirty (30) seconds:
<Report Findings Here> 6G-3.2.7.1 The mechanism for enforcing dual-control and dual-occupancy must be automated.
6G-3.2.7.1.a Examine documented policies and procedures to verify that the defined enforcement mechanism is automated. Documented policies and procedures reviewed: <Report Findings Here> 6G-3.2.7.1.b Observe enforcement mechanism configuration to verify it is automated. Identify the P2PE Assessor who confirms the enforcement mechanism configuration is automated:
<Report Findings Here> 6G-3.2.7.2 The system must enforce anti-pass-back.
6G-3.2.7.2.a Examine documented policies and procedures to …
Describe how the observation of authorized personnel accessing the Level 3 environment verified that dual-control access and dual-occupancy is enforced such that the room is never occupied by one person alone for more than thirty (30) seconds:
<Report Findings Here> 6G-3.2.7.1 The mechanism for enforcing dual-control and dual-occupancy must be automated.
6G-3.2.7.1.a Examine documented policies and procedures to verify that the defined enforcement mechanism is automated. Documented policies and procedures reviewed: <Report Findings Here> 6G-3.2.7.1.b Observe enforcement mechanism configuration to verify it is automated. Identify the P2PE Assessor who confirms the enforcement mechanism configuration is automated:
<Report Findings Here> 6G-3.2.7.2 The system must enforce anti-pass-back.
6G-3.2.7.2.a Examine documented policies and procedures to …
Added
p. 197
Documented policies and procedures reviewed: <Report Findings Here> 6G-3.2.7.4.b Observe mechanisms in use to verify that the system automatically generates an alarm event and an audit event when one person is alone in the room for more than 30 seconds.
Describe how the observed mechanisms in use verified that the system automatically generates an alarm event and an audit event when one person is alone in the room for more than 30 seconds:
<Report Findings Here> 6G-3.2.7.4.c Examine a sample of audit events and interview security personnel to verify that the audit events are followed up by security personnel. Sample of audit events reviewed: <Report Findings Here> Security personnel interviewed: <Report Findings Here> 6G-3.2.8 Access to the Level 3 room must create an audit event, which must be logged.
6G-3.2.8 Observe authorized personnel enter the environment and examine correlating audit logs to verify that access to the Level 3 room creates an audit …
Describe how the observed mechanisms in use verified that the system automatically generates an alarm event and an audit event when one person is alone in the room for more than 30 seconds:
<Report Findings Here> 6G-3.2.7.4.c Examine a sample of audit events and interview security personnel to verify that the audit events are followed up by security personnel. Sample of audit events reviewed: <Report Findings Here> Security personnel interviewed: <Report Findings Here> 6G-3.2.8 Access to the Level 3 room must create an audit event, which must be logged.
6G-3.2.8 Observe authorized personnel enter the environment and examine correlating audit logs to verify that access to the Level 3 room creates an audit …
Added
p. 198
<Report Findings Here> 6G-3.2.9.1.c If motion-activated systems are used for monitoring, observe system configurations for the motion-activated systems to verify they are separate from the intrusion-detection system.
Describe how the configurations observed for motion-activated systems verified that they are separate from the intrusion-detection system:
<Report Findings Here> 6G-3.2.9.2 The cameras must record to time-lapse VCRs or similar mechanisms, with a minimum of five frames equally recorded over every three seconds.
6G-3.2.9.2 Examine monitoring system configurations to verify; The system records to time-lapse VCRs or similar mechanisms.
A minimum of five frames are recorded every three seconds.
A minimum of five frames are recorded every three seconds.
Describe how the monitoring system configurations observed verified that:
The system records to time-lapse VCRs or similar mechanisms.
6G-3.2.9.3.a Observe the Level 3 physical environment to verify that continuous or motion-activated lighting is provided for each camera monitoring the environment.
<Report Findings Here> 6G-3.2.9.3.b Examine a sample of captured …
Describe how the configurations observed for motion-activated systems verified that they are separate from the intrusion-detection system:
<Report Findings Here> 6G-3.2.9.2 The cameras must record to time-lapse VCRs or similar mechanisms, with a minimum of five frames equally recorded over every three seconds.
6G-3.2.9.2 Examine monitoring system configurations to verify; The system records to time-lapse VCRs or similar mechanisms.
A minimum of five frames are recorded every three seconds.
A minimum of five frames are recorded every three seconds.
Describe how the monitoring system configurations observed verified that:
The system records to time-lapse VCRs or similar mechanisms.
6G-3.2.9.3.a Observe the Level 3 physical environment to verify that continuous or motion-activated lighting is provided for each camera monitoring the environment.
<Report Findings Here> 6G-3.2.9.3.b Examine a sample of captured …
Added
p. 199
Documented access policies and procedures reviewed: <Report Findings Here> 6G-3.2.9.5.b Examine Level 3 access lists as well as access controls to the media containing surveillance data, to verify that personnel with access to the Level 3 environment do not have access to the media containing recorded surveillance data.
Describe how the Level 3 access lists and access controls to the media containing surveillance data examined verified that personnel with access to the Level 3 environment do not have access to the media containing recorded surveillance data:
<Report Findings Here> 6G-3.2.9.6 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days.
6G-3.2.9.6.a Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived. Identify the P2PE Assessor who confirms that at least the most recent 45 days of images are securely <Report Findings Here> 6G-3.2.9.6.b If …
Describe how the Level 3 access lists and access controls to the media containing surveillance data examined verified that personnel with access to the Level 3 environment do not have access to the media containing recorded surveillance data:
<Report Findings Here> 6G-3.2.9.6 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days.
6G-3.2.9.6.a Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived. Identify the P2PE Assessor who confirms that at least the most recent 45 days of images are securely <Report Findings Here> 6G-3.2.9.6.b If …
Added
p. 203
<Report Findings Here> 6G-3.6.1.c For a sample of documented alarm events, review the record to verify that personnel authorized to sign off on alarm events were not also the cause of that event.
Sample of documented alarm events reviewed: <Report Findings Here> Alarm event records reviewed: <Report Findings Here> 6G-3.6.2 The use of any emergency entry or exit mechanism must cause an alarm event.
6G-3.6.2.a Examine security system configurations to verify that an alarm event is generated upon use of any emergency entry or exit mechanism. Describe how the observed security system configurations verified that an alarm event is generated upon use of any emergency entry or exit mechanism:
<Report Findings Here> 6G-3.6.2.b Conduct a test to verify the mechanisms work appropriately. Describe the testing performed that verified the mechanisms work appropriately:
<Report Findings Here> 6G-3.6.3 All alarms for physical intrusion necessitate an active response within 30 minutes by personnel assigned security duties.
6G-3.6.3.a Review …
Sample of documented alarm events reviewed: <Report Findings Here> Alarm event records reviewed: <Report Findings Here> 6G-3.6.2 The use of any emergency entry or exit mechanism must cause an alarm event.
6G-3.6.2.a Examine security system configurations to verify that an alarm event is generated upon use of any emergency entry or exit mechanism. Describe how the observed security system configurations verified that an alarm event is generated upon use of any emergency entry or exit mechanism:
<Report Findings Here> 6G-3.6.2.b Conduct a test to verify the mechanisms work appropriately. Describe the testing performed that verified the mechanisms work appropriately:
<Report Findings Here> 6G-3.6.3 All alarms for physical intrusion necessitate an active response within 30 minutes by personnel assigned security duties.
6G-3.6.3.a Review …
Added
p. 204
Describe how the observed system configurations for access, intrusion- detection, and monitoring (camera) systems verified that time and date stamps are synchronized:
<Report Findings Here> 6G-3.7.c Examine a sample of logs from the access, intrusion-detection, and monitoring (camera) systems to verify log time and date stamps are synchronized.
Sample of logs from the access, intrusion-detection, and monitoring (camera) systems reviewed:
<Report Findings Here> 6G-3.7.1 If a manual synchronization process is used, synchronization must occur at least quarterly; and documentation of the synchronization must be retained for at least a one-year period.
6G-3.7.1.a If a manual synchronization process is implemented, interview responsible personnel and examine records of synchronization to verify the mechanism is performed at least quarterly.
Responsible personnel interviewed: <Report Findings Here> Records of synchronization examined: <Report Findings Here> 6G-4.7.1.b Examine records of the synchronization process to verify that documentation is retained for at least one year. Records of synchronization examined: <Report Findings Here>
6B-1 All …
<Report Findings Here> 6G-3.7.c Examine a sample of logs from the access, intrusion-detection, and monitoring (camera) systems to verify log time and date stamps are synchronized.
Sample of logs from the access, intrusion-detection, and monitoring (camera) systems reviewed:
<Report Findings Here> 6G-3.7.1 If a manual synchronization process is used, synchronization must occur at least quarterly; and documentation of the synchronization must be retained for at least a one-year period.
6G-3.7.1.a If a manual synchronization process is implemented, interview responsible personnel and examine records of synchronization to verify the mechanism is performed at least quarterly.
Responsible personnel interviewed: <Report Findings Here> Records of synchronization examined: <Report Findings Here> 6G-4.7.1.b Examine records of the synchronization process to verify that documentation is retained for at least one year. Records of synchronization examined: <Report Findings Here>
6B-1 All …
Added
p. 205
6A-1 Account data is processed in equipment that conforms to requirements for secure cryptographic devices (SCDs). Account data never appears in the clear outside of an SCD.
6B Cryptographic keys used for account-data encryption/decryption and related key management are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
Sending and receiving entities are equally responsible for the physical protection of the materials involved.
6B Cryptographic keys used for account-data encryption/decryption and related key management are created using processes that ensure it is not possible to predict any key or determine that certain keys are more probable than other keys.
Sending and receiving entities are equally responsible for the physical protection of the materials involved.
Added
p. 206
6D-1 Secret and private keys must be input into hardware (host) security modules (HSMs) and Point of Interaction (POI) devices in a secure manner.
a) Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge.
b) Key-establishment techniques using public-key cryptography must be implemented securely.
6D-2 The mechanisms used to load secret and private keys•such as terminals, external PIN pads, key guns, or similar devices and methods•must be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component.
6D-3 All hardware and access/authentication mechanisms (e.g., passwords) used for key loading or the signing of authenticated applications (e.g., for “whitelists”) must be managed under dual control.
6D-5 Documented procedures must exist and be demonstrably in use (including audit trails) for all key-loading activities.
a) Unencrypted secret or private keys must be entered into cryptographic devices using the principles of dual control and split knowledge.
b) Key-establishment techniques using public-key cryptography must be implemented securely.
6D-2 The mechanisms used to load secret and private keys•such as terminals, external PIN pads, key guns, or similar devices and methods•must be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component.
6D-3 All hardware and access/authentication mechanisms (e.g., passwords) used for key loading or the signing of authenticated applications (e.g., for “whitelists”) must be managed under dual control.
6D-5 Documented procedures must exist and be demonstrably in use (including audit trails) for all key-loading activities.
Added
p. 207
6F-3 Keys generated using reversible key-calculation methods, such as key variants, must only be used in SCDs that possess the original key.
Keys generated using reversible key-calculation methods must not be used at different levels of the key hierarchy. For example, a variant of a key-encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.
Keys generated with a non-reversible process, such as key derivation or transformation process with a base key using an encipherment process, are not subject to these requirements.
6F-4 Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.
6F-6 Logs must be kept for any time that keys, key components or related materials are removed from storage or loaded to an SCD.
6F-7 Backups of secret and private keys must exist only for the purpose of reinstating …
Keys generated using reversible key-calculation methods must not be used at different levels of the key hierarchy. For example, a variant of a key-encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.
Keys generated with a non-reversible process, such as key derivation or transformation process with a base key using an encipherment process, are not subject to these requirements.
6F-4 Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.
6F-6 Logs must be kept for any time that keys, key components or related materials are removed from storage or loaded to an SCD.
6F-7 Backups of secret and private keys must exist only for the purpose of reinstating …
Added
p. 208
6G-2 Physical and logical protections must exist for deployed POI devices.
6I-1 For component providers of key-injection services: maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
Table 6B.1
• List of keys (by type) loaded onto POI devices via key-injection Key type/ description*: Purpose/function of the key (including types of devices using key): Identity of KIF:
* Note: Must include all keys from Table 6.1 identified as being distributed via KIF.
Domain 6: Normative Annex B, Key-Injection Facilities
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 6A-1.2 Key-injection facilities must only inject keys into equipment that conforms to the requirements for SCDs.
Key-injection platforms and systems shall include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs.
6A-1.2.a Examine documented procedures and system documentation to verify that key-injection platforms and systems used for managing cryptographic keys are required to conform to …
6I-1 For component providers of key-injection services: maintain and monitor critical P2PE controls and provide reporting to the responsible solution provider.
Table 6B.1
• List of keys (by type) loaded onto POI devices via key-injection Key type/ description*: Purpose/function of the key (including types of devices using key): Identity of KIF:
* Note: Must include all keys from Table 6.1 identified as being distributed via KIF.
Domain 6: Normative Annex B, Key-Injection Facilities
• Reporting Requirements and Testing Procedures Reporting Instructions and Assessor’s Findings 6A-1.2 Key-injection facilities must only inject keys into equipment that conforms to the requirements for SCDs.
Key-injection platforms and systems shall include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs.
6A-1.2.a Examine documented procedures and system documentation to verify that key-injection platforms and systems used for managing cryptographic keys are required to conform to …
Added
p. 210
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 6A-1.4 The approval listing must match the deployed devices in the following characteristics:
Vendor name Model name and number Hardware version number Firmware version number The PCI PTS HSM or FIPS 140 version with which the model complies The PCI PTS or FIPS 140 Approval Number For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 6A-1.4.a For all PCI-approved HSMs used, examine HSM devices and review the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
Vendor name Model name/number Hardware version number Firmware version number The PCI PTS HSM or FIPS 140 version with which the model complies The PCI …
Vendor name Model name and number Hardware version number Firmware version number The PCI PTS HSM or FIPS 140 version with which the model complies The PCI PTS or FIPS 140 Approval Number For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 6A-1.4.a For all PCI-approved HSMs used, examine HSM devices and review the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
Vendor name Model name/number Hardware version number Firmware version number The PCI PTS HSM or FIPS 140 version with which the model complies The PCI …
Added
p. 211
Maintain current documentation that describes or illustrates the architecture of the KIF, including all distributed KIF functionality.
Maintain documentation detailing the flow of keys from the key generation, through the distributed functionality to the destination device. The documentation should indicate how personnel interaction and inventory management is integrated into the flow.
6A-1.5.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
Relevant personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6A-1.5.b Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.
Relevant personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6A-1.5.c Examine the key-management flows and interview personnel to verify:
Documentation shows all key-management flows across functions and networks …
Maintain documentation detailing the flow of keys from the key generation, through the distributed functionality to the destination device. The documentation should indicate how personnel interaction and inventory management is integrated into the flow.
6A-1.5.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
Relevant personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6A-1.5.b Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.
Relevant personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6A-1.5.c Examine the key-management flows and interview personnel to verify:
Documentation shows all key-management flows across functions and networks …
Added
p. 212
6B-2.1.1.a Examine documented procedures to verify the following:
Documented procedures reviewed: <Report Findings Here> 6B-2.1.1.b Observe key-generation processes and interview responsible personnel to verify:
There is no mechanism including connectivity that might disclose a clear- text key or key component between the key-generation device and the device or medium receiving the key or key component.
Responsible personnel interviewed: <Report Findings Here> Describe how the key generation processes observed verified that any clear- text output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key:
<Report Findings Here> Describe how the key generation processes observed verified that there is no mechanism including connectivity that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component:
Note: Full-length key components or key shares derived using a recognized …
Documented procedures reviewed: <Report Findings Here> 6B-2.1.1.b Observe key-generation processes and interview responsible personnel to verify:
There is no mechanism including connectivity that might disclose a clear- text key or key component between the key-generation device and the device or medium receiving the key or key component.
Responsible personnel interviewed: <Report Findings Here> Describe how the key generation processes observed verified that any clear- text output of the key-generation process is overseen by only the assigned key custodian(s) for that component/share and is limited to those individual components and not the entire key:
<Report Findings Here> Describe how the key generation processes observed verified that there is no mechanism including connectivity that might disclose a clear-text key or key component between the key-generation device and the device or medium receiving the key or key component:
Note: Full-length key components or key shares derived using a recognized …
Added
p. 213
6B-2.1.2.a Observe the process from end to end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Describe how the end-to-end process observed verified that there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key:
<Report Findings Here> 6B-2.1.2.b Examine key-generation logs to verify that at least two individuals performed the key-generation processes. Key-generation logs reviewed: <Report Findings Here> 6B-2.1.3 Devices used for generation of clear-text key components that are output in the clear must be powered off when not in use. Logically partitioned devices used concurrently for other processes
•e.g., providing services simultaneously to host systems, such as for transaction processing
•must have key-generation capabilities disabled …
Describe how the end-to-end process observed verified that there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key:
<Report Findings Here> 6B-2.1.2.b Examine key-generation logs to verify that at least two individuals performed the key-generation processes. Key-generation logs reviewed: <Report Findings Here> 6B-2.1.3 Devices used for generation of clear-text key components that are output in the clear must be powered off when not in use. Logically partitioned devices used concurrently for other processes
•e.g., providing services simultaneously to host systems, such as for transaction processing
•must have key-generation capabilities disabled …
Added
p. 214
Describe how the physical security controls observed verified that key- component/key-generation process cannot be observed or accessed by unauthorized personnel:
<Report Findings Here> 6B-2.2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
For example, it is not permitted for the cryptographic key to be passed through the memory of a computer unless it has been specifically tasked for the sole purpose of key loading. Computers that have been specifically purposed and used solely for key loading are permitted for use if all other requirements can be met, including those of 6B-1 and the controls defined in Requirements at 6D-2 of this Annex B.
Single-purpose computers with an installed SCD where clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) meet this requirement. Where the components pass …
<Report Findings Here> 6B-2.2 Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory.
For example, it is not permitted for the cryptographic key to be passed through the memory of a computer unless it has been specifically tasked for the sole purpose of key loading. Computers that have been specifically purposed and used solely for key loading are permitted for use if all other requirements can be met, including those of 6B-1 and the controls defined in Requirements at 6D-2 of this Annex B.
Single-purpose computers with an installed SCD where clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) meet this requirement. Where the components pass …
Added
p. 215
Printers used for this purpose are not used for other purposes.
Describe how processes observed for printing key components verified that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output:
<Report Findings Here> 6B-2.3.c Observe blind mailers or other sealed containers used for key components to verify that tampering can be visually detected. Describe how the blind mailers or other sealed containers used for key components observed verified that tampering can be visually detected:
<Report Findings Here> 6B-2.4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted
•depending on media
•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
Any residue that may contain clear-text keys or components is destroyed immediately after generation.
Describe how the destruction process …
Describe how processes observed for printing key components verified that key components are printed within blind mailers or sealed immediately after printing, such that no one but the authorized custodian ever has physical access to the output:
<Report Findings Here> 6B-2.3.c Observe blind mailers or other sealed containers used for key components to verify that tampering can be visually detected. Describe how the blind mailers or other sealed containers used for key components observed verified that tampering can be visually detected:
<Report Findings Here> 6B-2.4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted
•depending on media
•immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
Any residue that may contain clear-text keys or components is destroyed immediately after generation.
Describe how the destruction process …
Added
p. 216
If a key is generated in a separate device before being exported into the end- use device, describe how the destruction process of the identified key residue observed verified that the key and all related critical security parameters are deleted from the generation and/or injection device immediately after the transfer to the device that will use the key:
Generated by the device that will use the key pair; or If generated externally, the private key of the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair.
6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are Generated by the device that will use the key pair, or If generated externally, the key pair and all related critical security parameters must …
Generated by the device that will use the key pair; or If generated externally, the private key of the key pair and all related critical security parameters (e.g., secret seeds) must be deleted (zeroized) immediately after the transfer to the device that will use the key pair.
6B-2.5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are Generated by the device that will use the key pair, or If generated externally, the key pair and all related critical security parameters must …
Added
p. 217
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Affixing (e.g., taping) key or component values to or inside devices Writing key or component values in procedure manual Documented policy and procedures reviewed: <Report Findings Here> 6B-2.6.b From observation of key-management processes verify that key components are not transmitted across insecure channels, including but not limited to:
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Affixing (e.g., taping) key …
Dictating verbally keys or components Recording key or component values on voicemail Faxing, e-mailing, or otherwise conveying clear-text keys or components Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging Writing key or component values into startup instructions Affixing (e.g., taping) key …
Added
p. 218
Documented key-generation procedures reviewed: <Report Findings Here> 6B-3.2.b Observe demonstrations for all types of key-generation events to verify that all key-generation events are logged. Describe how the demonstrations for all types of key-generation events observed verified that all key-generation events are logged:
<Report Findings Here> 6B-3.2.c Examine logs of key generation to verify that exchanges of higher- level keys with other organizations have been recorded. Key generation logs examined: <Report Findings Here> 6C-1.1 Keys must be transferred either encrypted or within an SCD. If clear text outside of an SCD, keys must be transferred as two or more key shares or full- length components using different communication channels, or within an SCD.
Where key components are transmitted in clear-text using pre-numbered tamper-evident, authenticable mailers:
- Ensure that details of the serial number of the package are conveyed transmitted separately from the package itself.
- Ensure that documented procedures exist and are followed to …
<Report Findings Here> 6B-3.2.c Examine logs of key generation to verify that exchanges of higher- level keys with other organizations have been recorded. Key generation logs examined: <Report Findings Here> 6C-1.1 Keys must be transferred either encrypted or within an SCD. If clear text outside of an SCD, keys must be transferred as two or more key shares or full- length components using different communication channels, or within an SCD.
Where key components are transmitted in clear-text using pre-numbered tamper-evident, authenticable mailers:
- Ensure that details of the serial number of the package are conveyed transmitted separately from the package itself.
- Ensure that documented procedures exist and are followed to …
Added
p. 220
Any person with access to one component/share of a key must not have access to other components/shares of this key, or to any other medium conveying any other components or shares sufficient to form the necessary threshold to derive the key.
An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Personnel interviewed: <Report Findings Here> Describe how the observed key-transfer processes verified that:
<Report Findings Here> 6C-1.3 E-mail …
An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
An individual with access to a key component or key share does not have access to other components/shares of this key or to any other medium conveying other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Personnel interviewed: <Report Findings Here> Describe how the observed key-transfer processes verified that:
<Report Findings Here> 6C-1.3 E-mail …
Added
p. 222
Under the continuous supervision of a person with authorized access to this component, Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access to it would be detected, or Contained within a physically secure SCD.
Under the continuous supervision of a person with authorized access to this component, Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access to it would be detected, or Contained within a physically secure SCD.
<Report Findings Here> 6C-2.2 Packaging or mailers (i.e., pre-numbered tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering must result in the destruction …
Under the continuous supervision of a person with authorized access to this component, Locked in a security container (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access to it would be detected, or Contained within a physically secure SCD.
<Report Findings Here> 6C-2.2 Packaging or mailers (i.e., pre-numbered tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering must result in the destruction …
Added
p. 224
Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
Describe how the implemented mechanisms and processes observed verified that only the authorized key custodians can perform the following:
<Report Findings Here> 6C-2.5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
Note: Numbered courier bags are not sufficient for this purpose 6C-2.5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
DEA keys used for encrypting keys must be at least double-length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
TDEA keys shall not be used …
Describe how the implemented mechanisms and processes observed verified that only the authorized key custodians can perform the following:
<Report Findings Here> 6C-2.5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
Note: Numbered courier bags are not sufficient for this purpose 6C-2.5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
DEA keys used for encrypting keys must be at least double-length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
TDEA keys shall not be used …
Added
p. 225
- TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
Appropriate personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> Describe how the key-generation processes observed verified that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, as delineated in Annex C:
<Report Findings Here> 6C-3.1.c Examine system documentation and configuration files to validate the above, including HSM settings. System documentation reviewed: <Report Findings Here> Describe how the observed configuration files validated the above, including HSM settings:
<Report Findings Here> 6C-4.1 Written procedures must exist and be known to all affected parties.
6C-4.2 Verify documented procedures include all methods used for the conveyance or receipt of keys. Documented procedures reviewed: <Report Findings Here>
Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens.
Describe how the structured …
Appropriate personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> Describe how the key-generation processes observed verified that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed, as delineated in Annex C:
<Report Findings Here> 6C-3.1.c Examine system documentation and configuration files to validate the above, including HSM settings. System documentation reviewed: <Report Findings Here> Describe how the observed configuration files validated the above, including HSM settings:
<Report Findings Here> 6C-4.1 Written procedures must exist and be known to all affected parties.
6C-4.2 Verify documented procedures include all methods used for the conveyance or receipt of keys. Documented procedures reviewed: <Report Findings Here>
Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens.
Describe how the structured …
Added
p. 226
6D-1.1.a Review documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required. Documented procedures reviewed: <Report Findings Here> 6D-1.1.b Interview appropriate personnel to determine the number of key components for each manually loaded key, and the methodology used to form the key.
Appropriate personnel interviewed: <Report Findings Here> 6D-1.1.c Witness a structured walk-through/demonstration of various key- loading processes for all key types (MFKs, TMKs, PEKs. etc.). Verify the number and length of the key components to information provided through verbal discussion and written documentation.
6D-1.2 Examine logs of access to security containers for key components to verify that only the authorized custodian(s) have accessed. Compare the number on the current tamper-evident authenticable bag for each component to the last log entry for that component.
Access logs examined: <Report Findings Here> 6D-1.3 The loading of clear-text cryptographic keys using a key-loading device …
Appropriate personnel interviewed: <Report Findings Here> 6D-1.1.c Witness a structured walk-through/demonstration of various key- loading processes for all key types (MFKs, TMKs, PEKs. etc.). Verify the number and length of the key components to information provided through verbal discussion and written documentation.
6D-1.2 Examine logs of access to security containers for key components to verify that only the authorized custodian(s) have accessed. Compare the number on the current tamper-evident authenticable bag for each component to the last log entry for that component.
Access logs examined: <Report Findings Here> 6D-1.3 The loading of clear-text cryptographic keys using a key-loading device …
Added
p. 227
Documented procedures reviewed: <Report Findings Here> 6D-1.3.b For all types of production SCDs, observe processes for loading clear- text cryptographic keys, including public keys, to verify that dual control is required to authorize any key-loading session. Verify that any passwords used are a minimum of five characters.
<Report Findings Here> 6D-1.4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components•e.g., via XOR‘ing of full-length components.
6D-1.4.a Examine documented procedures for combining symmetric key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components.
Describe how the key-component lengths or device configuration settings observed verified that key components used to create a key are the same length as the resultant key:
<Report Findings Here> 6D-1.5 …
<Report Findings Here> 6D-1.4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components•e.g., via XOR‘ing of full-length components.
6D-1.4.a Examine documented procedures for combining symmetric key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components.
Describe how the key-component lengths or device configuration settings observed verified that key components used to create a key are the same length as the resultant key:
<Report Findings Here> 6D-1.5 …
Added
p. 228
Asymmetric techniques Manual techniques The existing TMK to encrypt the replacement TMK for download.
Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use.
Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device actually has (or actually can) compute the session key and that no entity other than the POI device specifically identified can possibly compute the session key.
6D-1.8.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the POI.
Use of public and private key lengths that are in accordance with Annex C for the algorithm in question.
Use of …
Keys shall not be reloaded by any methodology in the event of a compromised device, and must be withdrawn from use.
Provide for mutual device authentication for both the host and the POI device or host-to-host if applicable, including assurance to the host that the POI device actually has (or actually can) compute the session key and that no entity other than the POI device specifically identified can possibly compute the session key.
6D-1.8.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the POI.
Use of public and private key lengths that are in accordance with Annex C for the algorithm in question.
Use of …
Added
p. 229
<Report Findings Here> 6D-1.9 Key-injection facilities must implement dual control and split-knowledge controls for the loading of keys into devices (e.g., POIs and other SCDs).
Note: Such controls may include but are not limited to:
Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key-loading equipment.
Access is restricted to only appropriate personnel involved in the key-loading process Logical dual control via multiple logins with unique user IDs to the key-injection platform application such that no one person can operate the application to singly inject cryptographic keys into devices Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store …
Note: Such controls may include but are not limited to:
Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to key injection such that the badge-access system enforces the presence of at least two authorized individuals at all times in the room so no one person can singly access the key-loading equipment.
Access is restricted to only appropriate personnel involved in the key-loading process Logical dual control via multiple logins with unique user IDs to the key-injection platform application such that no one person can operate the application to singly inject cryptographic keys into devices Key-injection platform applications that force the entry of multiple key components and the implementation of procedures that involve multiple key custodians who store …
Added
p. 230
Ensure that any cameras that are present are positioned to ensure they cannot monitor the entering of clear-text key components.
- SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
- An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device.
- There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys.
- The SCD is inspected to ensure it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying material.
Documented procedures reviewed: <Report Findings Here> Describe how the demonstration verified that:
An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device.
There is not any mechanism …
- SCDs must be inspected to detect evidence of monitoring and to ensure dual-control procedures are not circumvented during key loading.
- An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device.
- There is not any mechanism (including cabling) at the interface between the conveyance medium and the SCD device that might disclose the transferred keys.
- The SCD is inspected to ensure it has not been subject to any prior tampering that could lead to the disclosure of clear-text keying material.
Documented procedures reviewed: <Report Findings Here> Describe how the demonstration verified that:
An SCD must transfer a plaintext secret or private key only when at least two authorized individuals are identified by the device.
There is not any mechanism …
Added
p. 231
The medium used for key loading is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future re-loading of the component into the cryptographic device); or All traces of the component are erased or otherwise destroyed from the electronic medium.
Describe how the observed key-loading processes verified that the injection process results in one of the following:
<Report Findings Here> 6D-2.4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:
6D-2.4.1 Verify the key-loading device is a physically secure SCD designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
Documented procedures reviewed: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is a physically secure SCD, designed and implemented in such a …
Describe how the observed key-loading processes verified that the injection process results in one of the following:
<Report Findings Here> 6D-2.4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:
6D-2.4.1 Verify the key-loading device is a physically secure SCD designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
Documented procedures reviewed: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is a physically secure SCD, designed and implemented in such a …
Added
p. 232
Describe how the observed processes for the use of key-loading devices verified that the key-loading device is under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it:
Documented procedures reviewed: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD:
<Report Findings Here> 6D-2.4.3.b Verify that authorized personnel inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.
Documented procedures reviewed: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that authorized personnel inspect the key-loading device, prior to use to ensure that a key-recording device has not been …
Documented procedures reviewed: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD:
<Report Findings Here> 6D-2.4.3.b Verify that authorized personnel inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs.
Documented procedures reviewed: <Report Findings Here> Describe how the observed processes for the use of key-loading devices verified that authorized personnel inspect the key-loading device, prior to use to ensure that a key-recording device has not been …
Added
p. 233
Requirement that media/devices are in the physical possession of only the designated component holder(s).
Documented procedures reviewed: <Report Findings Here> 6D-2.5.c Interview designated component holder(s) and examine key- management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder.
6D-2.6 Validate through interview and observation that, if components are in human-readable form, they are visible only to the designated key-component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
<Report Findings Here> 6D-2.7 Written or printed key-component documents must not be opened until immediately prior to use.
6D-2.7.a Review documented procedures and confirm that printed/written key- component documents are not opened until immediately prior to use. Documented procedures reviewed: <Report Findings Here> 6D-2.7.b Observe key-loading processes and verify that printed/written key components are not opened until immediately prior to …
Documented procedures reviewed: <Report Findings Here> 6D-2.5.c Interview designated component holder(s) and examine key- management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder.
6D-2.6 Validate through interview and observation that, if components are in human-readable form, they are visible only to the designated key-component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
<Report Findings Here> 6D-2.7 Written or printed key-component documents must not be opened until immediately prior to use.
6D-2.7.a Review documented procedures and confirm that printed/written key- component documents are not opened until immediately prior to use. Documented procedures reviewed: <Report Findings Here> 6D-2.7.b Observe key-loading processes and verify that printed/written key components are not opened until immediately prior to …
Added
p. 234
Documented procedures reviewed: <Report Findings Here> 6D-2.8.b Examine key-component access controls and access logs to verify that any single authorized custodians can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key.
Describe how the observed key-component access controls and access logs verified that any single authorized custodian can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key:
<Report Findings Here> 6D-2.9 Key-injection facilities that use PC-based key-loading software platforms or similar devices (e.g., modified PEDs) that allow clear-text secret and/or private keys and/or their components to exist in unprotected memory outside the secure boundary of an SCD must minimally implement the following additional controls:
6D-2.9 Interview appropriate personnel and review documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key-loading platform. Review any logs of key loading.
Appropriate personnel interviewed: …
Describe how the observed key-component access controls and access logs verified that any single authorized custodian can only access their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key:
<Report Findings Here> 6D-2.9 Key-injection facilities that use PC-based key-loading software platforms or similar devices (e.g., modified PEDs) that allow clear-text secret and/or private keys and/or their components to exist in unprotected memory outside the secure boundary of an SCD must minimally implement the following additional controls:
6D-2.9 Interview appropriate personnel and review documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key-loading platform. Review any logs of key loading.
Appropriate personnel interviewed: …
Added
p. 235
6D-2.9.2 Verify through interviews and observation that:
All hardware used in key loading (including the PC) is managed under dual control.
All hardware used in key loading (including the PC) is managed under dual control.
Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.
Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.
Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals <Report Findings Here> 6D-2.9.3 PC access and use must be monitored, and logs of all key loading must be maintained. These logs must be retained for a minimum of three years. The logs must be regularly (no …
All hardware used in key loading (including the PC) is managed under dual control.
All hardware used in key loading (including the PC) is managed under dual control.
Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.
Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.
Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals <Report Findings Here> 6D-2.9.3 PC access and use must be monitored, and logs of all key loading must be maintained. These logs must be retained for a minimum of three years. The logs must be regularly (no …
Added
p. 236
Logs include a minimum of:
- Access to the room from a badge access system,
- Access to the room from a manual sign-in sheet,
- User sign-on logs on the PC at the operating system level,
- User sign-on logs on the PC at the application level,
- Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection,
- Video surveillance logs with a minimum retention period of 45 days.
Personnel interviewed: <Report Findings Here> Logs of key-loading activities reviewed: <Report Findings Here> 6D-2.9.4 Additionally:
6D-2.9.4 Verify through interviews and observation that: Personnel interviewed for 6D-2.9.4.x: <Report Findings Here> 6D-2.9.4.1 Cable attachments and the key-loading device must be examined before each use to ensure the equipment is free from tampering.
6D-2.9.4.1 Cable attachments and the key-loading device are examined before each use to ensure the equipment is free from tampering. Describe how it was …
- Access to the room from a badge access system,
- Access to the room from a manual sign-in sheet,
- User sign-on logs on the PC at the operating system level,
- User sign-on logs on the PC at the application level,
- Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection,
- Video surveillance logs with a minimum retention period of 45 days.
Personnel interviewed: <Report Findings Here> Logs of key-loading activities reviewed: <Report Findings Here> 6D-2.9.4 Additionally:
6D-2.9.4 Verify through interviews and observation that: Personnel interviewed for 6D-2.9.4.x: <Report Findings Here> 6D-2.9.4.1 Cable attachments and the key-loading device must be examined before each use to ensure the equipment is free from tampering.
6D-2.9.4.1 Cable attachments and the key-loading device are examined before each use to ensure the equipment is free from tampering. Describe how it was …
Added
p. 237
6D-2.9.4.5 Personnel responsible for the systems administration of the PC do not have authorized access into the room•i.e., they are escorted by authorized key-injection personnel•and do not have user IDs or passwords to operate the key-injection application.
Describe how it was verified that personnel responsible for the systems administration of the PC do not have authorized access into the room and do not have user IDs or passwords to operate the key-injection application:
<Report Findings Here> 6D-2.9.4.6 The key-injection personnel must not have system-administration capability at either the O/S or the application level on the PC.
6D-2.9.4.6 Key-injection personnel do not have system-administration capability at either the O/S or the application level on the PC. Describe how it was verified that key-injection personnel do not have system- administration capability at either the O/S or the application level on the PC:
<Report Findings Here> 6D-2.9.4.7 The PC must not be able to boot from external …
Describe how it was verified that personnel responsible for the systems administration of the PC do not have authorized access into the room and do not have user IDs or passwords to operate the key-injection application:
<Report Findings Here> 6D-2.9.4.6 The key-injection personnel must not have system-administration capability at either the O/S or the application level on the PC.
6D-2.9.4.6 Key-injection personnel do not have system-administration capability at either the O/S or the application level on the PC. Describe how it was verified that key-injection personnel do not have system- administration capability at either the O/S or the application level on the PC:
<Report Findings Here> 6D-2.9.4.7 The PC must not be able to boot from external …
Added
p. 238
Note: For DUKPT implementations, the BDK should be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC applications that require passwords to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords are maintained under dual control and split knowledge.
6D-2.9.4.9 If the PC application stores keys (e.g., BDKs or TMKs) on portable electronic media (e.g., smart cards), the media is secured as components under dual control when not in use. The key components are manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
Describe how it was verified that if the PC application stores keys on portable electronic media:
The media is secured as components under dual control when not in use.
The key …
6D-2.9.4.9 If the PC application stores keys (e.g., BDKs or TMKs) on portable electronic media (e.g., smart cards), the media is secured as components under dual control when not in use. The key components are manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
Describe how it was verified that if the PC application stores keys on portable electronic media:
The media is secured as components under dual control when not in use.
The key …
Added
p. 239
6D-3.2.a Review documented procedures to ensure they require that cable attachments be examined prior to key-loading function. Documented procedures reviewed: <Report Findings Here> 6D-3.2.b Observe key-loading processes to verify that all cable attachments are properly examined prior to a key-loading function. Describe how the key-loading processes observed verified that all cable attachments are properly examined prior to key-loading functions:
<Report Findings Here> 6D-3.3 Key-loading equipment usage must be monitored and a log of all key-loading activities maintained for audit purposes containing at a minimum date, time, personnel involved, and number of devices keys are loaded to.
6D-3.3.a Observe key-loading activities to verify that key-loading equipment usage is monitored. Describe how the key-loading activities observed verified that key-loading equipment usage is monitored:
<Report Findings Here> 6D-3.3.b Verify logs of all key-loading activities are maintained and contain all required information. Logs of key-loading activities reviewed: <Report Findings Here> 6D-3.4 Any physical tokens (e.g., brass keys …
<Report Findings Here> 6D-3.3 Key-loading equipment usage must be monitored and a log of all key-loading activities maintained for audit purposes containing at a minimum date, time, personnel involved, and number of devices keys are loaded to.
6D-3.3.a Observe key-loading activities to verify that key-loading equipment usage is monitored. Describe how the key-loading activities observed verified that key-loading equipment usage is monitored:
<Report Findings Here> 6D-3.3.b Verify logs of all key-loading activities are maintained and contain all required information. Logs of key-loading activities reviewed: <Report Findings Here> 6D-3.4 Any physical tokens (e.g., brass keys …
Added
p. 240
<Report Findings Here> 6D-3.5 Default password or PINs used to enforce dual-control must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.
6D-3.5.a Verify that documented procedures require default passwords or PINs used to enforce dual control are changed. Documented procedures reviewed: <Report Findings Here> 6D-3.5.b Verify that documented procedures exist to require that these passwords/PINs be changed when assigned personnel change. Documented procedures reviewed: <Report Findings Here> 6D-4.1 A cryptographic-based validation mechanism must be is in place to ensure the authenticity and integrity of keys and/or their components (e.g., testing key check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded, or displayed, key-component check values and key check values shall not exceed six hexadecimal characters in length.
6D-4.1.a Examine documented procedures to verify …
6D-3.5.a Verify that documented procedures require default passwords or PINs used to enforce dual control are changed. Documented procedures reviewed: <Report Findings Here> 6D-3.5.b Verify that documented procedures exist to require that these passwords/PINs be changed when assigned personnel change. Documented procedures reviewed: <Report Findings Here> 6D-4.1 A cryptographic-based validation mechanism must be is in place to ensure the authenticity and integrity of keys and/or their components (e.g., testing key check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded, or displayed, key-component check values and key check values shall not exceed six hexadecimal characters in length.
6D-4.1.a Examine documented procedures to verify …
Added
p. 241
<Report Findings Here> 6D-5.1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POIs), and all parties involved in cryptographic key loading must be aware of those procedures.
Responsible personnel interviewed: <Report Findings Here> 6D-5.1.c Observe key-loading process for keys loaded as components and verify that the documented procedures are demonstrably in use. This may be done as necessary on test equipment•e.g., for HSMs.
<Report Findings Here> 6D-5.2 All key-loading events must be documented. Audit trails must be in place for all key-loading events.
<Report Findings Here> 6E-2.2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the destruction and invalidation of all associated key components and the …
Responsible personnel interviewed: <Report Findings Here> 6D-5.1.c Observe key-loading process for keys loaded as components and verify that the documented procedures are demonstrably in use. This may be done as necessary on test equipment•e.g., for HSMs.
<Report Findings Here> 6D-5.2 All key-loading events must be documented. Audit trails must be in place for all key-loading events.
<Report Findings Here> 6E-2.2 To prevent or detect usage of a compromised key, key-component packaging or containers that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
6E-2.2.a Verify documented procedures require that key-component packaging/containers showing signs of tampering must result in the destruction and invalidation of all associated key components and the …
Added
p. 242
Note: Controls include physical access to the room, logical access to the key-loading application, video surveillance of activities in the key-injection room, physical access to secret or private cryptographic key components or shares, etc.
6E-2.4.a Examine documented key-injection procedures to verify that controls are defined to prevent and detect the loading of keys by any one single person. Documented procedures reviewed: <Report Findings Here> 6E-2.4.b Interview responsible personnel and observe key-loading processes and controls to verify that controls
•e.g., viewing CCTV images implemented to prevent and detect the loading of keys by any one single person.
Responsible personnel interviewed: <Report Findings Here> Describe how the key-loading processes and controls observed verified that controls are implemented to prevent and detect the loading of keys by any one single person:
<Report Findings Here> 6E-2.5 Key-injection facilities must implement controls to protect against unauthorized substitution of keys and to prevent the operation of devices without legitimate keys.
Examples …
6E-2.4.a Examine documented key-injection procedures to verify that controls are defined to prevent and detect the loading of keys by any one single person. Documented procedures reviewed: <Report Findings Here> 6E-2.4.b Interview responsible personnel and observe key-loading processes and controls to verify that controls
•e.g., viewing CCTV images implemented to prevent and detect the loading of keys by any one single person.
Responsible personnel interviewed: <Report Findings Here> Describe how the key-loading processes and controls observed verified that controls are implemented to prevent and detect the loading of keys by any one single person:
<Report Findings Here> 6E-2.5 Key-injection facilities must implement controls to protect against unauthorized substitution of keys and to prevent the operation of devices without legitimate keys.
Examples …
Added
p. 243
<Report Findings Here> 6E-3.2 Private keys must only be used as follows:
Private keys shall never be used to encrypt other keys.
6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only To create digital signatures or to perform decryption operations.
For a single purpose•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices).
6E-3.3 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that public keys are only To perform encryption operations or to verify digital signatures.
Key-management documentation reviewed: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed: <Report Findings Here> 6E-3.4 Keys must never be shared or substituted between production and test/development systems:
Key used for production keys must never be present or used in a test system, and …
Private keys shall never be used to encrypt other keys.
6E-3.2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are only To create digital signatures or to perform decryption operations.
For a single purpose•a private key must only be used for either decryption or for creating digital signatures, but not both (except for POI devices).
6E-3.3 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that public keys are only To perform encryption operations or to verify digital signatures.
Key-management documentation reviewed: <Report Findings Here> Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed: <Report Findings Here> 6E-3.4 Keys must never be shared or substituted between production and test/development systems:
Key used for production keys must never be present or used in a test system, and …
Added
p. 244
Describe how the observed processes for generating and loading keys into production systems verified that they are in no way associated with test or development keys:
<Report Findings Here> 6E-3.4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys for higher-level keys (e.g., MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.
Describe how the observed compared check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) verified that development and test keys have different key values:
<Report Findings Here> 6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the key-injection server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials …
<Report Findings Here> 6E-3.4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys for higher-level keys (e.g., MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.
Describe how the observed compared check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) verified that development and test keys have different key values:
<Report Findings Here> 6E-3.5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the key-injection server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials …
Added
p. 245
Documented procedures reviewed: <Report Findings Here> 6E-4.1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POIs to verify that unique keys are generated and used for each POI device.
<Report Findings Here> 6E-4.1.c Examine check values, hashes, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI vendor used) to determine that the associated private keys stored in the POI devices are unique per device•i.e., the public keys are unique.
<Report Findings Here> 6E-4.2 If a POI device directly interfaces with more than one entity for decryption of account data (e.g., a different acquiring organization), the POI must have a completely different and unique key or set of keys for each acquiring organization. …
<Report Findings Here> 6E-4.1.c Examine check values, hashes, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI vendor used) to determine that the associated private keys stored in the POI devices are unique per device•i.e., the public keys are unique.
<Report Findings Here> 6E-4.2 If a POI device directly interfaces with more than one entity for decryption of account data (e.g., a different acquiring organization), the POI must have a completely different and unique key or set of keys for each acquiring organization. …
Added
p. 246
Unique data is used for the derivation process such that all transaction- originating POIs receive unique secret keys.
Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
Documented procedures reviewed: <Report Findings Here> Describe how the processes observed for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:
<Report Findings Here> 6E-4.3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device. Describe how the processes observed for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into a POI device:
<Report Findings Here> 6E-4.4 Entities processing or injecting DUKPT or other key-derivation methodologies for more than one …
Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI.
Documented procedures reviewed: <Report Findings Here> Describe how the processes observed for generating master keys verified that the following is implemented where master keys are generated by a derivation process and derived from the same Base Derivation Key:
<Report Findings Here> 6E-4.3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device. Describe how the processes observed for generating master keys verified that derivation keys used to generate keys for multiple devices are never loaded into a POI device:
<Report Findings Here> 6E-4.4 Entities processing or injecting DUKPT or other key-derivation methodologies for more than one …
Added
p. 247
6E-4.5.a If the key-injection facility loads DUKPT keys, examine documented procedures for generation and use of BDKs to verify they require use of separate BDKs per terminal type.
Documented procedures reviewed: <Report Findings Here> 6E-4.5.b Observe key-loading processes for a sample of terminal types used by a single entity, to verify that separate BDKs are used for each terminal type. Sample of terminal types used by a single entity reviewed: <Report Findings Here> Describe how the key-loading processes observed verified that separate BDKs are used for each terminal type:
<Report Findings Here> 6E-4.6 Remote Key-Establishment and Distribution Applications The following requirements apply to key-injection facilities participating in remote key-establishment and distribution applications:
Keys must be uniquely identifiable in all hosts and POI Devices (e.g., EPPs/PEDs). Keys must be identifiable via cryptographically verifiable means (e.g., through the use of digital signatures or key check values).
Key pairs must be unique per POI device …
Documented procedures reviewed: <Report Findings Here> 6E-4.5.b Observe key-loading processes for a sample of terminal types used by a single entity, to verify that separate BDKs are used for each terminal type. Sample of terminal types used by a single entity reviewed: <Report Findings Here> Describe how the key-loading processes observed verified that separate BDKs are used for each terminal type:
<Report Findings Here> 6E-4.6 Remote Key-Establishment and Distribution Applications The following requirements apply to key-injection facilities participating in remote key-establishment and distribution applications:
Keys must be uniquely identifiable in all hosts and POI Devices (e.g., EPPs/PEDs). Keys must be identifiable via cryptographically verifiable means (e.g., through the use of digital signatures or key check values).
Key pairs must be unique per POI device …
Added
p. 248
6F-1.2 Examine documented procedures and interview responsible personnel to determine all instances where key components are used. Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-1.2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key.
6F-1.2.1 Review processes for creating key components to verify that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key.
Describe how the processes observed for creating key components verified that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key:
6F-1.2.2 Observe processes for constructing cryptographic keys to verify that at least two key components are required for each key construction. Describe how the processes observed for constructing keys verified that at least two key components are required for each key construction:
Key-management documentation reviewed: <Report …
6F-1.2.1 Review processes for creating key components to verify that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key.
Describe how the processes observed for creating key components verified that knowledge of any one key component does not convey any knowledge of any part of the actual cryptographic key:
6F-1.2.2 Observe processes for constructing cryptographic keys to verify that at least two key components are required for each key construction. Describe how the processes observed for constructing keys verified that at least two key components are required for each key construction:
Key-management documentation reviewed: <Report …
Added
p. 249
In an m-of-n scheme where n =5 and where all three components are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key components (e.g., component A and component B), as a second custodian (with, in this example, component C) would be required to reconstruct the final key, ensuring that dual control is maintained.
Describe how the key-component access controls and access logs observed verified that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key:
<Report Findings Here> 6F-1.3 Key components must be stored as follows:
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-1.3.1 Key components that exist in clear text clear-text outside of an SCD must be sealed in opaque, pre-numbered tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
Note: Tamper-evident, …
Describe how the key-component access controls and access logs observed verified that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key:
<Report Findings Here> 6F-1.3 Key components must be stored as follows:
Documented procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6F-1.3.1 Key components that exist in clear text clear-text outside of an SCD must be sealed in opaque, pre-numbered tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
Note: Tamper-evident, …
Added
p. 250
Identify the P2PE Assessor who confirms that tamper-evident packaging prevents the determination of the key component without visible damage to the packaging:
<Report Findings Here> 6F-1.3.1.c Interview responsible personnel to determine that clear-text key components do not exist in any other locations, including in non-secure containers, in databases, on floppy disks, or in software programs.
Responsible personnel interviewed: <Report Findings Here> 6F-1.3.1.d Confirm that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear (e.g., at the point in the checklist where the keys are entered).
<Report Findings Here> 6F-1.3.3 If a key component is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner (or designated backup(s)) must have possession of both the token and its access code.
<Report Findings Here> 6F-2.1 Procedures for known or suspected compromised keys must …
<Report Findings Here> 6F-1.3.1.c Interview responsible personnel to determine that clear-text key components do not exist in any other locations, including in non-secure containers, in databases, on floppy disks, or in software programs.
Responsible personnel interviewed: <Report Findings Here> 6F-1.3.1.d Confirm that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear (e.g., at the point in the checklist where the keys are entered).
<Report Findings Here> 6F-1.3.3 If a key component is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner (or designated backup(s)) must have possession of both the token and its access code.
<Report Findings Here> 6F-2.1 Procedures for known or suspected compromised keys must …
Added
p. 251
6F-2.1.1 Interview responsible personnel and observe implemented processes to verify key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised:
<Report Findings Here> 6F-2.1.2 If unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.
6F-2.1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.
Responsible personnel interviewed: <Report Findings Here> Describe …
Responsible personnel interviewed: <Report Findings Here> Describe how the implemented processes observed verified that key components are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised:
<Report Findings Here> 6F-2.1.2 If unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.
6F-2.1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.
Responsible personnel interviewed: <Report Findings Here> Describe …
Added
p. 252
Describe how the implemented processes observed verified that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, all the following are performed:
6F-2.1.4.a Interview responsible personnel and review documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
Responsible personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6F-2.1.4.b Verify notifications include the following:
A damage assessment including, where necessary, the engagement of outside consultants.
Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
<Report Findings Here> 6F-2.1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:
Missing secure cryptographic devices Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log …
6F-2.1.4.a Interview responsible personnel and review documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
Responsible personnel interviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> 6F-2.1.4.b Verify notifications include the following:
A damage assessment including, where necessary, the engagement of outside consultants.
Details of specific actions to be taken with system software and hardware, encryption keys, encrypted data, etc.
<Report Findings Here> 6F-2.1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to:
Missing secure cryptographic devices Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log …
Added
p. 253
Missing SCDs Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation Documented procedures reviewed: <Report Findings Here> 6F-2.2 If attempts to load a secret key or key component into a KLD or POI fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI 6F-2.2 Interview responsible personnel …
Added
p. 254
<Report Findings Here> 6F-3.3 Reversible key transformations are not used across different levels of the key hierarchy. For example, reversible transformations must not generate working keys (e.g., PEKs) from key-encrypting keys.
Note: Using transforms of keys across different levels of a key hierarchy
•e.g., generating a PEK key from a key-encrypting key
•increases the risk of exposure of each of those keys.
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as a PIN key, MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
Variants used as KEKs must only be calculated from other key-encrypting keys.
Variants of working keys must only be calculated from other working …
Note: Using transforms of keys across different levels of a key hierarchy
•e.g., generating a PEK key from a key-encrypting key
•increases the risk of exposure of each of those keys.
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as a PIN key, MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
Variants used as KEKs must only be calculated from other key-encrypting keys.
Variants of working keys must only be calculated from other working …
Added
p. 255
<Report Findings Here> Responsible personnel interviewed: <Report Findings Here> Key-history logs examined: <Report Findings Here> Key-destruction logs examined: <Report Findings Here> 6F-4.1.c Review storage locations for the sample of destroyed keys to verify they are no longer kept. Describe how the storage locations observed verified that the sample of destroyed keys are no longer kept:
<Report Findings Here> 6F-4.2 The procedures for destroying keys or key components that are no longer used or that have been replaced by a new key must be documented and sufficient to ensure that no part of the key or component can be recovered. This must be accomplished by use of a cross-cut shredder, pulping or burning. Strip- shredding is not sufficient.
<Report Findings Here> 6F-4.2.1 Keys on all other storage media types in all permissible forms•physically secured, enciphered (except for electronic DB backups of cryptograms), or components
•must be destroyed following the procedures outlined in ISO
•9564 or …
<Report Findings Here> 6F-4.2 The procedures for destroying keys or key components that are no longer used or that have been replaced by a new key must be documented and sufficient to ensure that no part of the key or component can be recovered. This must be accomplished by use of a cross-cut shredder, pulping or burning. Strip- shredding is not sufficient.
<Report Findings Here> 6F-4.2.1 Keys on all other storage media types in all permissible forms•physically secured, enciphered (except for electronic DB backups of cryptograms), or components
•must be destroyed following the procedures outlined in ISO
•9564 or …
Added
p. 256
6F-4.2.3.a Verify documented procedures exist for destroying key components of keys, once the keys are successfully loaded and validated as operational. Documented procedures reviewed: <Report Findings Here> 6F-4.2.3.b Observe key-conveyance/loading processes to verify that any key components are destroyed once the keys are successfully loaded and validated as operational.
<Report Findings Here> 6F-5.1 To reduce the opportunity for key compromise, limit the number of key custodians to the minimum required for operational efficiency.
6F-5.1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following: Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed: <Report Findings Here> 6F-5.1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. Key custodians must be employees or contracted personnel 6F-5.1.1 Review key-custodian assignments for each component to verify that:
Assigned key …
<Report Findings Here> 6F-5.1 To reduce the opportunity for key compromise, limit the number of key custodians to the minimum required for operational efficiency.
6F-5.1 Interview key custodians and key-management supervisory personnel and observe implemented processes to verify the following: Key custodians interviewed: <Report Findings Here> Key-management supervisory personnel interviewed: <Report Findings Here> 6F-5.1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. Key custodians must be employees or contracted personnel 6F-5.1.1 Review key-custodian assignments for each component to verify that:
Assigned key …
Added
p. 257
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access 6F-5.1.3 Examine all key-custodian forms to verify that they include the following:
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access Completed key-custodian forms reviewed: <Report Findings Here> 6F-5.1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted …
Specific authorization for the custodian Identification of the custodian’s responsibilities for safeguarding key components or other keying material entrusted to them Signature of the custodian acknowledging their responsibilities An effective date for the custodian’s access Signature of management authorizing the access Completed key-custodian forms reviewed: <Report Findings Here> 6F-5.1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted …
Added
p. 258
Documented procedures reviewed: <Report Findings Here> 6F-6.1 Logs must be kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD. These logs must be archived for a minimum of two years subsequent to key destruction.
Removed from secure storage Loaded to an SCD Log files reviewed: <Report Findings Here> Describe how the audit log settings observed verified that logs are kept for any time that keys, key components, or related materials are:
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable) Log files reviewed: <Report Findings Here> Describe how the audit log settings observed verified that logs include the following:
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number …
Removed from secure storage Loaded to an SCD Log files reviewed: <Report Findings Here> Describe how the audit log settings observed verified that logs are kept for any time that keys, key components, or related materials are:
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number (if applicable) Log files reviewed: <Report Findings Here> Describe how the audit log settings observed verified that logs include the following:
Date and time in/out Key-component identifier Purpose of access Name and signature of custodian accessing the component Tamper-evident package number …
Added
p. 259
Observe backup processes to verify backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys.
Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows:
- Securely stored with proper access controls
- Under at least dual control
- Subject to at least the same level of security control as operational keys as specified in this document Documented procedures reviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> Backup records reviewed: <Report Findings Here> Describe how the backup processes observed verified that backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys:
Creation (including cloning) must require a minimum of two authorized individuals to enable the process.
The creation of any backup …
Inspect backup storage locations and access controls or otherwise verify through examination of documented procedures and interviews of personnel that backups are maintained as follows:
- Securely stored with proper access controls
- Under at least dual control
- Subject to at least the same level of security control as operational keys as specified in this document Documented procedures reviewed: <Report Findings Here> Documented procedures reviewed: <Report Findings Here> Backup records reviewed: <Report Findings Here> Describe how the backup processes observed verified that backup copies of secret and/or private keys are maintained in accordance with the same requirements as are followed for the primary keys:
Creation (including cloning) must require a minimum of two authorized individuals to enable the process.
The creation of any backup …
Added
p. 261
6G-1.1.1 Review documented procedures to verify controls are defined to protect POIs and other SCDs from unauthorized access up to point of deployment.
Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.1 Access to all POIs and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
6G-1.1.1.1.a Examine access-control documentation and device configurations to verify that access to all POIs and key-injection/loading devices is defined and documented.
Access-control documentation reviewed: <Report Findings Here> Describe how the device configurations observed verified that access to all POIs and key injection/loading devices is defined and documented:
<Report Findings Here> 6G-1.1.1.1.b For a sample of POIs and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all POIs and other SCDs is logged.
Sample of POIs and other SCDs: <Report Findings Here> Access logs reviewed: <Report Findings Here> Describe how the observation …
Documented procedures reviewed: <Report Findings Here> 6G-1.1.1.1 Access to all POIs and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
6G-1.1.1.1.a Examine access-control documentation and device configurations to verify that access to all POIs and key-injection/loading devices is defined and documented.
Access-control documentation reviewed: <Report Findings Here> Describe how the device configurations observed verified that access to all POIs and key injection/loading devices is defined and documented:
<Report Findings Here> 6G-1.1.1.1.b For a sample of POIs and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all POIs and other SCDs is logged.
Sample of POIs and other SCDs: <Report Findings Here> Access logs reviewed: <Report Findings Here> Describe how the observation …
Added
p. 262
All personnel with access to POIs and other SCDs are documented in a formal list.
All personnel with access to POIs and other SCDs are authorized by management.
Documented authorizations reviewed: <Report Findings Here> 6G-1.1.1.3.b For a sample of POIs and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in the formal list have access to devices.
Sample of POIs and other SCDs reviewed: <Report Findings Here> Describe how the implemented access controls observed verified that only personnel documented and authorized in the formal list have access to <Report Findings Here> 6G-1.2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt through to placement into service.
The chain of custody must include records to identify responsible personnel for each interaction with the devices.
6G-1.2.a Examine documented processes to verify that the chain of custody is required for devices from receipt to …
All personnel with access to POIs and other SCDs are authorized by management.
Documented authorizations reviewed: <Report Findings Here> 6G-1.1.1.3.b For a sample of POIs and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in the formal list have access to devices.
Sample of POIs and other SCDs reviewed: <Report Findings Here> Describe how the implemented access controls observed verified that only personnel documented and authorized in the formal list have access to <Report Findings Here> 6G-1.2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt through to placement into service.
The chain of custody must include records to identify responsible personnel for each interaction with the devices.
6G-1.2.a Examine documented processes to verify that the chain of custody is required for devices from receipt to …
Added
p. 263
Transportation using a trusted courier service (e.g., via bonded carrier). The devices are then securely stored until key-insertion and deployment occurs.
Use of physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging). The devices are then stored in such packaging, or in secure storage, until key insertion and deployment occurs.
A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. Before key-insertion, the SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.
Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized access or modifications. (Note: Unauthorized access includes that …
Use of physically secure and trackable packaging (e.g., pre-serialized, counterfeit-resistant, tamper-evident packaging). The devices are then stored in such packaging, or in secure storage, until key insertion and deployment occurs.
A secret, device-unique “transport-protection token” is loaded into the secure storage area of each device at the manufacturer’s facility. Before key-insertion, the SCD used for key-insertion verifies the presence of the correct “transport-protection token” before overwriting this value with the initial key, and the device is further protected until deployment.
Each cryptographic device is carefully inspected and tested immediately prior to key-insertion and deployment using due diligence. This is done to provide reasonable assurance that it is the legitimate device and that it has not been subject to any unauthorized access or modifications. (Note: Unauthorized access includes that …
Added
p. 264
Sample of received devices: <Report Findings Here> Sender documentation/record of serial- number validations reviewed: <Report Findings Here> 6G-1.4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required in account data-processing equipment to support specified functionality must be disabled before the equipment is commissioned.
6G-1.4.2.a Obtain and review the defined security policy to be enforced by the HSM Documented security policy reviewed: <Report Findings Here> 6G-1.4.2.b Examine documentation of the HSM configuration settings to determine that the functions and command authorized to be enabled are in accordance with the security policy.
HSM configuration settings documentation reviewed: <Report Findings Here> 6G-1.4.2.c For a sample of HSMs, review the configuration settings to determine that only authorized functions are enabled. Sample of HSMs reviewed: <Report Findings Here> Describe how the HSM configuration settings observed verified that only authorized functions are enabled:
<Report Findings …
6G-1.4.2.a Obtain and review the defined security policy to be enforced by the HSM Documented security policy reviewed: <Report Findings Here> 6G-1.4.2.b Examine documentation of the HSM configuration settings to determine that the functions and command authorized to be enabled are in accordance with the security policy.
HSM configuration settings documentation reviewed: <Report Findings Here> 6G-1.4.2.c For a sample of HSMs, review the configuration settings to determine that only authorized functions are enabled. Sample of HSMs reviewed: <Report Findings Here> Describe how the HSM configuration settings observed verified that only authorized functions are enabled:
<Report Findings …
Added
p. 265
Responsible personnel interviewed: <Report Findings Here> Describe how the inspection processes observed verified that processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or <Report Findings Here> 6G-1.4.3.4 Maintaining records of the tests and inspections, and retaining records for at least one year 6G-1.4.3.4.a Examine records of inspections and interview responsible personnel to verify records of the tests and inspections are maintained. Records of inspections examined: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 6G-1.4.3.4.b Examine records of inspections to verify records are retained for at least one year. Records of inspections examined: <Report Findings Here> 6G-1.4 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation.
6G-1.4.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation. Documented procedures reviewed: <Report Findings Here> 6G-1.4.b Observe a …
6G-1.4.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation. Documented procedures reviewed: <Report Findings Here> 6G-1.4.b Observe a …
Added
p. 266
Each production run must be associated with a predefined inventory of identified POI devices to be injected or initialized with keys.
Unauthorized personnel must not be able to modify this inventory without detection.
All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory.
Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated.
Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices must be identified and accounted for against the inventory.
Note: The KIF platform must ensure that only authorized devices can ever be injected or initialized with authorized keys. Processes must prevent (1) substitution of an authorized device with an unauthorized device, and (2) insertion of an unauthorized device into a production run.
6G-2.3.a Obtain and review documentation of inventory control and monitoring procedures. Determine …
Unauthorized personnel must not be able to modify this inventory without detection.
All POI devices to be initialized with keys on a production run must be identified and accounted for against the inventory.
Unauthorized POI devices submitted for injection or initialized must be rejected by the injection platform and investigated.
Once processed by the KIF, whether successfully initialized with keys or not, all submitted POI devices must be identified and accounted for against the inventory.
Note: The KIF platform must ensure that only authorized devices can ever be injected or initialized with authorized keys. Processes must prevent (1) substitution of an authorized device with an unauthorized device, and (2) insertion of an unauthorized device into a production run.
6G-2.3.a Obtain and review documentation of inventory control and monitoring procedures. Determine …
Added
p. 267
6G-3.1.1.a Review documented procedures for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.
Documented procedures reviewed: <Report Findings Here> 6G-3.1.1.b Interview personnel and observe demonstration (if HSM is available) of processes for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes Personnel interviewed: <Report Findings Here> Describe how the demonstration verified that dual control is implemented for all critical decommissioning processes:
<Report Findings Here> 6G-3.1.2 Keys are rendered irrecoverable (e.g., zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.
6G-3.1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify that all keying material is rendered irrecoverable (e.g., zeroized), or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data …
Documented procedures reviewed: <Report Findings Here> 6G-3.1.1.b Interview personnel and observe demonstration (if HSM is available) of processes for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes Personnel interviewed: <Report Findings Here> Describe how the demonstration verified that dual control is implemented for all critical decommissioning processes:
<Report Findings Here> 6G-3.1.2 Keys are rendered irrecoverable (e.g., zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.
6G-3.1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify that all keying material is rendered irrecoverable (e.g., zeroized), or that devices are physically destroyed under dual control to prevent the disclosure of any sensitive data …
Added
p. 268
6G-3.1.6 Interview personnel and observe records to verify that records of the tests and inspections are maintained for at least one year. Personnel interviewed: <Report Findings Here> Records of testing examined: <Report Findings Here> 6G-4.1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, procedures must be documented and implemented to protect against unauthorized access and use.
6G-4.1 Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, and that they cover the requirements at 6G-4.1.1 through 6G-4.1.5 below.
Documented procedures reviewed: <Report Findings Here> 6G-4.1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented …
6G-4.1 Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, and that they cover the requirements at 6G-4.1.1 through 6G-4.1.5 below.
Documented procedures reviewed: <Report Findings Here> 6G-4.1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented …
Added
p. 271
Responsible personnel interviewed: <Report Findings Here> Identify the P2PE Assessor who confirms that the documented procedures are followed for key conveyance or transmittal for keys used between KIF components:
<Report Findings Here> 6G-4.9.5 The KIF must implement a mutually authenticated channel for establishment of enciphered secret or private keys between POI devices and an HSM at the KIF.
6G-4.9.5 Examine documented procedures to confirm they specify the establishment of a mutually authenticated channel for establishment of enciphered secret or private keys between sending and receiving devices• e.g., POI devices and HSMs.
Documented procedures reviewed: <Report Findings Here> 6G-4.9.6 Mutual authentication of the sending and receiving devices must be performed.
KIFs must validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM it must not be possible to insert …
<Report Findings Here> 6G-4.9.5 The KIF must implement a mutually authenticated channel for establishment of enciphered secret or private keys between POI devices and an HSM at the KIF.
6G-4.9.5 Examine documented procedures to confirm they specify the establishment of a mutually authenticated channel for establishment of enciphered secret or private keys between sending and receiving devices• e.g., POI devices and HSMs.
Documented procedures reviewed: <Report Findings Here> 6G-4.9.6 Mutual authentication of the sending and receiving devices must be performed.
KIFs must validate authentication credentials of a POI prior to any key transport, exchange, or establishment with that device.
When a KLD is used as an intermediate device to establish keys between POIs and a KIF HSM it must not be possible to insert …
Added
p. 272
6G-4.10.1 Inspect the secure area designated for key injection to verify that it is constructed with extended walls from the real floor to the real ceiling using sheetrock or wire mesh.
Identify the P2PE Assessor who confirms that the secure area designated for key injections is constructed with extended walls from the real floor to the real ceiling using sheetrock or wire mesh:
<Report Findings Here> 6G-4.10.2 Any windows into the secure room must be locked and protected by alarmed sensors.
6G-4.10.2.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors. Identify the P2PE Assessor who confirms all windows in the secure room are locked and protected by alarmed sensors:
<Report Findings Here> 6G-4.10.3 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.
6G-4.10.3 Observe all windows in the secure room to verify they are covered, rendered opaque, or …
Identify the P2PE Assessor who confirms that the secure area designated for key injections is constructed with extended walls from the real floor to the real ceiling using sheetrock or wire mesh:
<Report Findings Here> 6G-4.10.2 Any windows into the secure room must be locked and protected by alarmed sensors.
6G-4.10.2.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors. Identify the P2PE Assessor who confirms all windows in the secure room are locked and protected by alarmed sensors:
<Report Findings Here> 6G-4.10.3 Any windows must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure area.
6G-4.10.3 Observe all windows in the secure room to verify they are covered, rendered opaque, or …
Added
p. 273
Dual-access for entry to the secure area Anti-pass-back Describe how the observation of authorized personnel entering the secure area verified that a badge-control system is in place that enforces the following requirements:
Dual-access for entry to the secure area Anti-pass-back <Report Findings Here> 6G-4.10.6 The badge-control system must support generation of an alarm when one person remains alone in the secure area for more than 30 seconds.
Note: Examples of alarm-generation mechanisms include but are not limited to motion detectors, login/logout controls, biometrics, badge sensors, etc.
6G-4.10.6 Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure area for more than 30 seconds.
Alarm-response personnel interviewed: <Report Findings Here> Describe how the alarm mechanisms observed verified that the badge-control system supports generation of an alarm when one person remains alone in the secure area …
Dual-access for entry to the secure area Anti-pass-back <Report Findings Here> 6G-4.10.6 The badge-control system must support generation of an alarm when one person remains alone in the secure area for more than 30 seconds.
Note: Examples of alarm-generation mechanisms include but are not limited to motion detectors, login/logout controls, biometrics, badge sensors, etc.
6G-4.10.6 Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure area for more than 30 seconds.
Alarm-response personnel interviewed: <Report Findings Here> Describe how the alarm mechanisms observed verified that the badge-control system supports generation of an alarm when one person remains alone in the secure area …
Added
p. 274
<Report Findings Here> 6G-4.10.9.b Inspect access-control configurations for the CCTV server/storage area and the key-injection area to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the key- injection area do not have access to the CCTV server/storage area.
Identify the P2PE Assessor who identified all personnel with access to the CCTV server/storage area and the key-injection area, and who confrms that personnel with access to the key- injection area do not have access to the CCTV server/storage area:
<Report Findings Here> 6G-4.10.10 The CCTV cameras must be positioned to monitor:
The entrance door, SCDs, both pre and post key injection, Any safes that are present, and The equipment used for key injection.
The entrance door, SCDs, both pre and post key injection, Any safes that are present, and The equipment used for key injection.
6G-4.10.10 Inspect …
Identify the P2PE Assessor who identified all personnel with access to the CCTV server/storage area and the key-injection area, and who confrms that personnel with access to the key- injection area do not have access to the CCTV server/storage area:
<Report Findings Here> 6G-4.10.10 The CCTV cameras must be positioned to monitor:
The entrance door, SCDs, both pre and post key injection, Any safes that are present, and The equipment used for key injection.
The entrance door, SCDs, both pre and post key injection, Any safes that are present, and The equipment used for key injection.
6G-4.10.10 Inspect …
Added
p. 275
Documented records reviewed: <Report Findings Here> 6I-1.1 Track status of key-management services for POIs and HSMs and provide reports to solution provider annually and upon significant changes, including at least the following:
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Note that adding, changing, or removing POI device and/or HSM types, or critical key management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding or removing elements of a P2PE solution.
6I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Documented component provider procedures reviewed: <Report Findings Here> Responsible component-provider personnel interviewed: <Report Findings Here> …
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Note that adding, changing, or removing POI device and/or HSM types, or critical key management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding or removing elements of a P2PE solution.
6I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:
- Key-distribution method Details of any known or suspected compromised keys, per 6F-2.1 Documented component provider procedures reviewed: <Report Findings Here> Responsible component-provider personnel interviewed: <Report Findings Here> …
Modified
p. 1
Payment Card Industry (PCI) Point-to-Point Encryption Template for Report on Validation for use with P2PE v2.0 (Revision 1.1) for P2PE Application validated as part of a Merchant-Managed Solution Revision 1.0
Payment Card Industry (PCI) Point-to-Point Encryption Template for Report on Validation for use with P2PE v2.0 (Revision 1.1) for P2PE Merchant-Managed Solution Revision 1.0
Modified
p. 4 → 5
Use of this Reporting Template is mandatory for completing a P2PE Report on Validation for a P2PE Application validated as part of a Merchant-Managed Solution that is not being listed.
Use of this Reporting Template is mandatory for completing a P2PE Report on Validation for MMS.
Modified
p. 4 → 5
A P2PE compliance assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The P-ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how …
A P2PE compliance assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists, interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The P-ROV is effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how …
Modified
p. 8 → 9
1. Contact Information and Report Date 1.1 Contact Information P2PE Application Vendor contact information Company name: Company URL:
1. Contact Information and Report Date 1.1 Contact Information P2PE MMS Provider contact information Company name: Company URL:
Modified
p. 8 → 9
Confirm that internal QA was fully performed on the entire P2PE validation documentation, per requirements in relevant program documentation.
Confirm that internal QA was fully performed on the entire P2PE submission, per requirements in relevant program documentation.
Removed
p. 10
2. Summary Overview 2.1 P2PE Application Details P2PE application name: Application Description of application function/purpose:
Description of how the application is designed (for example, as a standalone application, in modules, or as part of a suite of applications):
Description of how application stores, processes and/or transmits account data:
Description of how the application is designed (for example, as a standalone application, in modules, or as part of a suite of applications):
Description of how application stores, processes and/or transmits account data:
Removed
p. 10
Define what types of changes the vendor includes as a “No Impact” change (refer to the P2PE Program Guide for information on what constitutes a No Impact Change):
Removed
p. 11
Note: P2PE applications and P2PE non-payment software do not meet the PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment (PTS firmware is not considered a P2PE payment application, nor is it P2PE non-payment software).
Modified
p. 11 → 14
Domain 1
• Encryption Device and Application ManagementN/A Domain 2
• Application SecurityYes No Domain 3
• P2PE Solution ManagementN/A Domain 4
• Merchant-managed Solutions N/A Domain 5
• Decryption EnvironmentN/A Domain 6
• P2PE Cryptographic Key Operations and Device ManagementN/A Domain 6
• Annex A1: Symmetric-Key Distribution using Asymmetric Techniques N/A
• Encryption Device and Application Management
• Application Security
• P2PE Solution Management
• Merchant-managed Solutions N/A Domain 5
• Decryption Environment
• P2PE Cryptographic Key Operations and Device Management
• Annex A1: Symmetric-Key Distribution using Asymmetric Techniques N/A
Domain 1
• Encryption Device and Application Management Yes No Domain 2
• Application Security N/A Domain 3
• P2PE Solution Management Yes No Domain 4
• Merchant-managed Solutions N/A Domain 5
• Decryption Environment Yes No Domain 6
• P2PE Cryptographic Key Operations and Device Management Yes No Domain 6
• Annex A1: Symmetric-Key Distribution using Asymmetric Techniques Yes No N/A Domain 6
• Annex A2: Certification and Registration Authority Operations Yes No N/A Domain 6
• Annex B: Key-Injection Facilities Yes No N/A
• Encryption Device and Application Management Yes No Domain 2
• Application Security N/A Domain 3
• P2PE Solution Management Yes No Domain 4
• Merchant-managed Solutions N/A Domain 5
• Decryption Environment Yes No Domain 6
• P2PE Cryptographic Key Operations and Device Management Yes No Domain 6
• Annex A1: Symmetric-Key Distribution using Asymmetric Techniques Yes No N/A Domain 6
• Annex A2: Certification and Registration Authority Operations Yes No N/A Domain 6
• Annex B: Key-Injection Facilities Yes No N/A
Removed
p. 13
Provide detailed descriptions and/or diagrams to illustrate how the application functions in a typical implementation.
For all application functions, provide the following: o Description of all application processes related to each function o Description of all communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels o Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application o Other necessary application functions or processes, as applicable Identify any functionality of the application that was not included in the assessment <Insert P2PE Application detailed diagram(s)> 3.2 Overview of P2PE Application data flow For each POI the application was tested on:
Provide high-level data flow diagram(s) that shows details of all flows of account data, including: o All flows and locations of encrypted account data (including data input, output, and within the POI) o …
For all application functions, provide the following: o Description of all application processes related to each function o Description of all communication channels, connection methods, and communication protocols used by the application for all internal and external communication channels o Details of any protection mechanisms (for example, encryption, truncation, masking, etc.) applied to account data by the application o Other necessary application functions or processes, as applicable Identify any functionality of the application that was not included in the assessment <Insert P2PE Application detailed diagram(s)> 3.2 Overview of P2PE Application data flow For each POI the application was tested on:
Provide high-level data flow diagram(s) that shows details of all flows of account data, including: o All flows and locations of encrypted account data (including data input, output, and within the POI) o …
Modified
p. 13 → 15
3. Details and Scope of P2PE Assessment 3.1 Application details For each POI the application was tested on:
3. Details and Scope of P2PE Assessment 3.1 Scoping Details Describe how the P2PE assessor validated the accuracy of the P2PE scope for the assessment, including:
Modified
p. 13 → 16
<Insert P2PE Application data flow diagram(s)>
<Insert P2PE MMS data flow diagram(s)>
Removed
p. 14
Description of component necessary for application functioning Type of component (for example, software, hardware) Role of component 3.4 Application authentication mechanisms Describe the application’s end-to-end authentication methods, as follows:
Authentication mechanisms:
Authentication database:
Security of authentication data storage:
Authentication mechanisms:
Authentication database:
Security of authentication data storage:
Modified
p. 16 → 19
Note: If the P2PE Application Implementation Guide consists of more than one document, the brief description below should explain the purpose of each document it includes, such as if it is for a different POIs, for different functions, etc.
Note: If the PIM or P2PE Application Implementation Guide consists of more than one document, the brief description below should explain the purpose of each document it includes, such as if it is for a different POIs, for different functions, etc.
Modified
p. 16 → 19
Reference # (optional use) Document Name (Title of the IG) Version Number of the IG Document date (latest version date) Which POI device type(s) is addressed? (Must align with Section 2.5) All other documentation reviewed for this P2PE Assessment:
Reference # (optional use) Document Name (Title of the IG) Version Number of the IG Document date (latest version date) Which P2PE Application is addressed? (Must align with Section 2.3) All other documentation reviewed for this P2PE Assessment:
Modified
p. 16 → 19
Reference # (optional use) Document Name (including version, if applicable) Document date (latest version date) Document Purpose 3.7 Individuals Interviewed List of all personnel interviewed for this Application assessment:
Reference # (optional use) Document Name (including version, if applicable) Document date (latest version date) Document Purpose
Modified
p. 16 → 37
Guidance in the Implementation Guide is followed.
Removed
p. 17
2A-2 The application does not store PAN and/or SAD for any longer than business processes require.
2A-3 The application does not transmit clear-text PAN and/or SAD outside of the POI device, and only uses communication methods included in the scope of the PCI-approved POI device evaluation.
2B Develop and maintain secure applications.
2B-1 The application is developed and tested according to industry-standard software development life cycle practices that incorporate information security.
2B-3 The application vendor uses secure protocols, provides guidance on their use, and performs integration testing on the final application.
2B-4 Applications do not implement any encryption functions in lieu of SRED encryption. All such functions are performed by the approved SRED firmware of the POI device.
2C-1 New vulnerabilities are discovered and applications are tested for those vulnerabilities on an ongoing basis.
2C-2 Applications are installed and updates are implemented only via trusted and cryptographically authenticated processes using an approved security mechanism evaluated for the …
2A-3 The application does not transmit clear-text PAN and/or SAD outside of the POI device, and only uses communication methods included in the scope of the PCI-approved POI device evaluation.
2B Develop and maintain secure applications.
2B-1 The application is developed and tested according to industry-standard software development life cycle practices that incorporate information security.
2B-3 The application vendor uses secure protocols, provides guidance on their use, and performs integration testing on the final application.
2B-4 Applications do not implement any encryption functions in lieu of SRED encryption. All such functions are performed by the approved SRED firmware of the POI device.
2C-1 New vulnerabilities are discovered and applications are tested for those vulnerabilities on an ongoing basis.
2C-2 Applications are installed and updates are implemented only via trusted and cryptographically authenticated processes using an approved security mechanism evaluated for the …
Modified
p. 17 → 21
4. Findings and Observations Domain 2: Application Security
• Summary of Findings Domain2: P2PE Validation Requirements Summary of Findings (check one) Place N/A Not in 2A Protect PAN and SAD 2A-1 The application executes on a PCI-approved POI device with SRED enabled and active.
• Summary of Findings Domain
4. Findings and Observations Domain 1: Encryption Device and Application Management
• Summary of Findings Domain 1: P2PE Validation Requirements Summary of Findings (check one) Place N/A Not in 1A Account data must be encrypted in equipment that is resistant to physical and logical compromise.
• Summary of Findings Domain 1: P2PE Validation Requirements Summary of Findings (check one) Place N/A Not in 1A Account data must be encrypted in equipment that is resistant to physical and logical compromise.
Modified
p. 17 → 21
1C-1 Applications are implemented securely, including when using shared resources and when updating applications and application functionality.
Modified
p. 17 → 21
1D Implement secure application-management processes.
Modified
p. 17 → 21
1D-2 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.
Removed
p. 18
2A-1.1 For each POI device type used by the application, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
2A-1.2 For each type of POI device being assessed as part of the application assessment, verify that the application only uses SRED-validated account data capture mechanisms.
<Report Findings Here> 2A-2.1 The application vendor must document all flows and justify all uses of PAN and/or SAD input into, processed by, and output from the application.
2A-2.1.a Interview software personnel and examine the application’s design documentation to verify it documents all flows and justifies all uses of PAN and/or SAD input into, processed by, and output from the application.
Software personnel interviewed: <Report Findings Here> Application design documentation reviewed: <Report Findings Here> 2A-2.1.b Perform a source-code review and verify that PAN and/or SAD are only utilized according …
2A-1.2 For each type of POI device being assessed as part of the application assessment, verify that the application only uses SRED-validated account data capture mechanisms.
<Report Findings Here> 2A-2.1 The application vendor must document all flows and justify all uses of PAN and/or SAD input into, processed by, and output from the application.
2A-2.1.a Interview software personnel and examine the application’s design documentation to verify it documents all flows and justifies all uses of PAN and/or SAD input into, processed by, and output from the application.
Software personnel interviewed: <Report Findings Here> Application design documentation reviewed: <Report Findings Here> 2A-2.1.b Perform a source-code review and verify that PAN and/or SAD are only utilized according …
Modified
p. 18 → 22
Model name and number Hardware version number Firmware version number SRED listed as a function provided.
Model name and number Hardware version number Firmware version number SRED listed as a function provided 1A-1.1 For each POI device type used in the solution, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
Modified
p. 18 → 22
Model name/number Hardware version number Firmware version number SRED listed as a function provided.
Model name/number Hardware version number Firmware version number SRED listed as a function provided For each POI device type used in the solution, describe how the POI device configurations and PCI SSC list of Approved PTS Devices verified that all of the POI device characteristics at 1A-1.1 match the PTS listing:
Modified
p. 18 → 22
For each POI device type used by the application, describe how the POI device configurations observed verified that all of the POI device characteristics at 2A- 1.1 match the PTS listing:
For each POI device type used in the solution, describe how the POI device configurations observed verified that SRED capabilities are enabled and active prior to being deployed to merchant encryption environments:
Modified
p. 18 → 22
<Report Findings Here> 2A-1.2 The application must only use the PTS SRED-validated account-data capture mechanisms of the underlying POI device for accepting and processing P2PE transactions.
<Report Findings Here> 1A-1.2 POI devices must be configured to use only SRED-validated account-data capture mechanisms.
Modified
p. 18 → 23
For each POI device type used in the application, describe how the application only uses SRED-validated account data capture mechanisms:
For each POI device type used in the solution, describe how the device configuration verified that each device type is configured by default to use only SRED-validated account-data capture mechanisms for accepting and processing P2PE transactions:
Modified
p. 18 → 138
<Report Findings Here> 2A-2.2 The application must not store PAN and/or SAD (even if encrypted) as follows:
<Report Findings Here> 6F-1.3 Key components must be stored as follows:
Removed
p. 19
How it ensures the application does not store PAN after the payment transaction is complete.
How it ensures the application does not store SAD after authorization is complete.
PAN is not stored after the payment transaction is completed.
PAN is not stored after the payment transaction is completed.
SAD is not stored after authorization is completed.
SAD is not stored after authorization is completed.
Describe how the source-code review verified that the application is designed such that PAN is not stored after the payment transaction is completed:
Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:
How it ensures the application does not store SAD after authorization is complete.
PAN is not stored after the payment transaction is completed.
PAN is not stored after the payment transaction is completed.
SAD is not stored after authorization is completed.
SAD is not stored after authorization is completed.
Describe how the source-code review verified that the application is designed such that PAN is not stored after the payment transaction is completed:
Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:
Removed
p. 19
2A-2.3.a Examine the application’s design documentation and verify it contains a detailed description of the function of the application, including how it ensures the application does not retain PAN and/or SAD in working memory any longer than strictly necessary.
Application design documentation reviewed: <Report Findings Here> 2A-2.3.b Perform a source-code review and verify that PAN and/or SAD is cleared from all working memory locations after use, including local variables (before exiting the function).
Describe how the source-code review verified that PAN and/or SAD is cleared from all working memory locations after use, including local variables (before exiting the function):
Application design documentation reviewed: <Report Findings Here> 2A-2.3.b Perform a source-code review and verify that PAN and/or SAD is cleared from all working memory locations after use, including local variables (before exiting the function).
Describe how the source-code review verified that PAN and/or SAD is cleared from all working memory locations after use, including local variables (before exiting the function):
Modified
p. 19 → 24
<Report Findings Here> Describe forensic tools and/or methods used to inspect the test transactions:
Identify the sample of transactions <Report Findings Here> Describe the forensic tools and/or other data tracing methods used to inspect the sample of transactions:
Modified
p. 19 → 35
How it uses PAN and/or SAD for its application processing.
Requires dual control for the application-signing process.
Modified
p. 19 → 35
Cryptographically authenticated by the POI device firmware, in accordance with the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 19 → 38
<Report Findings Here> 2A-2.3 The application must not retain PAN and/or SAD in working memory any longer than strictly necessary.
<Report Findings Here> 1D-1.3 The application must be configured to securely integrate with any device resources that may be shared with other applications.
Modified
p. 19 → 124
Documented procedures reviewed: <Report Findings Here> 6D-2.3.b Observe key-loading processes to verify that the injection process results in one of the following:
Modified
p. 19 → 259
<Report Findings Here> Describe how the source-code review verified that the application is designed such that SAD is not stored after authorization is completed:
<Report Findings Here> Describe how the backup storage locations observed verified that backups are maintained as follows:
Removed
p. 20
Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application clears all working memory locations utilized for the temporal retention of PAN and/or SAD during processing.
<Report Findings Here> 2A-2.4 The application must securely delete any PAN and/or SAD stored during application processing.
2A-2.4.a Examine the application’s design documentation and verify it describes the process used by the application to securely delete any PAN and/or SAD stored during application processing.
Application design documentation reviewed: <Report Findings Here> 2A-2.4.b Perform a source-code review and verify that the process provided by the application vendor renders all stored PAN and/or SAD irrecoverable once application processing is completed, in accordance with industry-accepted standards for secure deletion of data.
Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the …
<Report Findings Here> 2A-2.4 The application must securely delete any PAN and/or SAD stored during application processing.
2A-2.4.a Examine the application’s design documentation and verify it describes the process used by the application to securely delete any PAN and/or SAD stored during application processing.
Application design documentation reviewed: <Report Findings Here> 2A-2.4.b Perform a source-code review and verify that the process provided by the application vendor renders all stored PAN and/or SAD irrecoverable once application processing is completed, in accordance with industry-accepted standards for secure deletion of data.
Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the …
Modified
p. 20 → 34
Cryptographically authenticated by the POI device’s firmware in accordance with the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 20 → 82
<Report Findings Here> 5D-1.14.5 All files must be securely deleted in accordance with industry-accepted standards for secure deletion of data:
Modified
p. 20 → 166
<Report Findings Here> Describe forensic tools and/or methods used to inspect the test transactions:
<Report Findings Here> Describe how key transfer and loading operations verified that the process ensures that key pairs are unique per POI device:
Modified
p. 20 → 201
<Report Findings Here> Describe forensic tools and/or methods used to inspect the test transactions:
<Report Findings Here> Describe how observing all but one authorized person who badged or otherwise authenticated into the system badge out and exit verified that IDS and alarms function correctly:
Modified
p. 20 → 236
<Report Findings Here> 2A-3.1 The application must not output clear-text account data outside of the POI device.
<Report Findings Here> 6D-2.9.4.3 The software application must load keys without recording any clear-text values on portable media or other unsecured devices.
Removed
p. 21
Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application does not output clear-text account data outside of the POI device.
<Report Findings Here> 2A-3.1.2 If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, this is ONLY allowable if the application includes the following:
The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms.
<Report Findings Here> 2A-3.1.2 If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, this is ONLY allowable if the application includes the following:
The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms.
Removed
p. 21
2A-3.1.2.a If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, examine the application’s design documentation and verify it contains a description of the application’s function, including that the printing of full PANs on merchant receipts is a legal/regulatory obligation.
Application design documentation reviewed: <Report Findings Here> 2A-3.1.2.b If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, perform a source-code review and verify the following:
The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and does not include any functionality that sends clear-text PANs to any devices attached via cabling or other networking mechanisms.
Describe how the source-code review verified that the application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the …
Application design documentation reviewed: <Report Findings Here> 2A-3.1.2.b If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, perform a source-code review and verify the following:
The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and does not include any functionality that sends clear-text PANs to any devices attached via cabling or other networking mechanisms.
Describe how the source-code review verified that the application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the …
Modified
p. 21 → 26
Note that Domain 1 (at 1B.1.1) and Domain 3 (at 3A-1.3) also include requirements that must be met for any POI device and for a P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
Note that Domain 2 (at 2A-3.1.2) and Domain 3 (at 3A-1.3) also include requirements that must be met for any P2PE application and P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
Modified
p. 21 → 57
<Report Findings Here> Describe forensic tools and/or methods used to inspect the test transactions:
<Report Findings Here> Describe how configurations of all devices and systems in the merchant decryption environment confirmed that none of the systems store account data:
Modified
p. 21 → 167
<Report Findings Here> Describe how the source-code review verified that the P2PE application securely deletes the clear-text PAN after completion of printing:
<Report Findings Here> Describe how the KDH configurations observed verified that KDHs only communicate with CAs for the purpose of certificate signing and certificate (entity) status checking:
Removed
p. 22
The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms.
Note: The application is allowed to share clear-text account data directly with the POI device’s SRED-approved firmware.
2A-3.2.a Examine the application’s Implementation Guide required at 2C-3 of this document and determine that it includes the following:
A list of all logical interfaces for the application, and the function/purpose of each.
The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device).
The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications).
Examine the logical interfaces used to communicate with other applications and confirm that the application cannot share clear-text account data with other applications via …
Note: The application is allowed to share clear-text account data directly with the POI device’s SRED-approved firmware.
2A-3.2.a Examine the application’s Implementation Guide required at 2C-3 of this document and determine that it includes the following:
A list of all logical interfaces for the application, and the function/purpose of each.
The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device).
The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications).
Examine the logical interfaces used to communicate with other applications and confirm that the application cannot share clear-text account data with other applications via …
Modified
p. 22 → 24
<Report Findings Here> 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications.
<Report Findings Here> 1A-2.1 All applications on POI devices with access to clear-text account data must be assessed according to Domain 2.
Modified
p. 22 → 33
Implementing whitelisting functionality in accordance with the device vendor's security guidance or the application’s Implementation Guide.
Modified
p. 22 → 68
Describe how the source-code review verified that the application cannot directly facilitate sharing of clear-text account data with other applications via its logical interfaces:
Describe how process flows and data flows verified that there is no process, application, or other mechanism that sends clear-text account data back into the encryption environment:
Modified
p. 22 → 130
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2A-3.2.a:
Identify the P2PE Assessor who confirms that the documented procedures for keys loaded as components are demonstrably in use:
Removed
p. 23
Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:
For example, the POI device may provide an IP stack approved per the PTS Open Protocols module, or the device may provide serial ports or modems approved by the PTS evaluation to communicate transaction data encrypted by its PCI PTS SRED functions.
Note: Using any external communication methods not included the PCI-approved POI device evaluation will invalidate the PTS approval and such use is prohibited in P2PE solutions.
2A-3.3.a Examine the POI device vendor’s security guidance to determine which external communication methods are approved via the PCI-approved POI device evaluation.
Review the application’s design documentation and verify that it contains a description of the application’s function including the following:
A list of the external communication methods included in the POI device …
For example, the POI device may provide an IP stack approved per the PTS Open Protocols module, or the device may provide serial ports or modems approved by the PTS evaluation to communicate transaction data encrypted by its PCI PTS SRED functions.
Note: Using any external communication methods not included the PCI-approved POI device evaluation will invalidate the PTS approval and such use is prohibited in P2PE solutions.
2A-3.3.a Examine the POI device vendor’s security guidance to determine which external communication methods are approved via the PCI-approved POI device evaluation.
Review the application’s design documentation and verify that it contains a description of the application’s function including the following:
A list of the external communication methods included in the POI device …
Modified
p. 23 → 139
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes guidance that the use of any other method for external communication is not allowed:
Identify the P2PE Assessor who confirms that clear-text key components do not exist in any other locations.
Removed
p. 24
2A-3.4.a For any whitelisting functionality implemented by the application, examine the application’s Implementation Guide required at 2C-3 of this document and verify it contains details to describe any whitelisting functionality and that it provides instructions as follows:
How to establish cryptographically authentication by the POI device’s firmware.
<Report Findings Here> 2B-1.1 Applications must be developed based on industry best practices and in accordance with the POI device vendor's security guidance, and information security is incorporated throughout the software development life cycle. These processes must include the following:
How to establish cryptographically authentication by the POI device’s firmware.
<Report Findings Here> 2B-1.1 Applications must be developed based on industry best practices and in accordance with the POI device vendor's security guidance, and information security is incorporated throughout the software development life cycle. These processes must include the following:
Modified
p. 24 → 27
That such functionality must be approved by authorized personnel prior to implementation.
The list of authorized personnel is reviewed at least annually.
Modified
p. 24 → 33
How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
Modified
p. 24 → 33
- Description and justification for the functionality.
- Description and justification for the functionality
Modified
p. 24 → 33
- Who approved the new installation or updated functionality prior to release.
- The identity of the authorized person who approved the new installation or updated functionality prior to release
Modified
p. 24 → 33
- Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data.
- Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Aligns with 2A-3.4
Modified
p. 24 → 33
That documentation for all new installations or updates to whitelist functionality includes the following:
Approval of functionality by authorized personnel prior to implementation Documentation for all new installations or updates to whitelist functionality that includes the following:
Modified
p. 24 → 34
Describe how test transactions verified that output of clear-text account data is only enabled for non-PCI payment brand account/card data:
Modified
p. 24 → 34
- Description and justification for the functionality.
- Description and justification for the functionality
Modified
p. 24 → 34
- Who approved the new installation or updated functionality prior to release.
- The identity of the authorized person who approved the new installation or updated functionality prior to release
Modified
p. 24 → 35
How to perform cryptographic authentication by the POI device’s firmware.
Is cryptographically authenticated by the POI device’s firmware.
Modified
p. 24 → 35
Confirmation that it was reviewed prior to release to only output non-PCI payment account/card data.
Modified
p. 24 → 38
<Report Findings Here> 1D-1.2.2 All applications must be cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
Modified
p. 24 → 69
That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data.
Cryptographic authentication by the HSM Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 24 → 69
That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data.
Cryptographic authentication by the HSM Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
Modified
p. 24 → 71
That such functionality must be approved by authorized personnel prior to implementation.
The documentation includes who approved it prior to implementation.
Modified
p. 24 → 71
That all new installations or updates to whitelist functionality must include the following:
Both new installations and updates to whitelisting functionality are documented.
Modified
p. 24 → 241
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2A-3.4.a:
Identify the P2PE Assessor who confirms that the documented procedures for keys loaded as components are demonstrably in use:
Removed
p. 25
Processes are based on industry standards and/or best practices.
Information security is included throughout the software development life cycle.
Applications are developed in accordance with all applicable P2PE requirements. .
Incorporated into the application developer’s written software development processes.
Implemented per the POI device vendor's security guidance.
POI device vendor’s security guidance documentation reviewed: <Report Findings Here> 2B-1.1.c Examine the application’s Implementation Guide required at 2C-3 of this document and verify it provides information from the POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).
Examine written software development processes and interview software developers.
Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel.
Examine the final application product.
Reporting responses at 2B-1.1.1 and 2B-1.1.2; no further reporting required here.
2B-1.1.1 Live PANs must not be used for testing or development.
2B-1.1.1 …
Information security is included throughout the software development life cycle.
Applications are developed in accordance with all applicable P2PE requirements. .
Incorporated into the application developer’s written software development processes.
Implemented per the POI device vendor's security guidance.
POI device vendor’s security guidance documentation reviewed: <Report Findings Here> 2B-1.1.c Examine the application’s Implementation Guide required at 2C-3 of this document and verify it provides information from the POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).
Examine written software development processes and interview software developers.
Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel.
Examine the final application product.
Reporting responses at 2B-1.1.1 and 2B-1.1.2; no further reporting required here.
2B-1.1.1 Live PANs must not be used for testing or development.
2B-1.1.1 …
Modified
p. 25 → 113
<Report Findings Here> 2B-1.1.d Verify each of the items at 2B-1.1.1 through 2B-1.1.3 by performing the following:
<Report Findings Here> 6C-1.1.b Where an SCD is used, perform the following:
Modified
p. 25 → 198
Identify the P2PE Assessor who confirms that the application’s Implementation Guide provides information from the POI device vendor’s security guidance applicable to the solution provider:
Identify the P2PE Assessor who confirms that continuous or motion- activated lighting is provided for each camera monitoring the Level 3 physical environment:
Modified
p. 25 → 215
Documented software development processes reviewed: <Report Findings Here> 2B-1.1.b Examine the POI device vendor’s security guidance, and verify that any specified software development processes are:
Documented procedures reviewed: <Report Findings Here> 6B-2.4.b Observe the destruction process of the identified key residue and verify the following:
Removed
p. 26
2B-1.1.2 Examine written software-development procedures and interview responsible personnel to verify that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers.
Documented software development processes reviewed: <Report Findings Here> Software developers interviewed: <Report Findings Here> Software-testing personnel interviewed: <Report Findings Here> Describe how testing documentation samples of test data and the final application product verified that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers:
<Report Findings Here> 2B-1.2 Application code and any non-code configuration mechanisms must be reviewed prior to every release or update.
2B-1.2 Examine written software-development procedures and interview responsible personnel to verify the application vendor performs reviews for all application code changes and non-code configuration mechanisms as follows:
Reviews are performed by an individual, other than the code author, who is …
Documented software development processes reviewed: <Report Findings Here> Software developers interviewed: <Report Findings Here> Software-testing personnel interviewed: <Report Findings Here> Describe how testing documentation samples of test data and the final application product verified that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers:
<Report Findings Here> 2B-1.2 Application code and any non-code configuration mechanisms must be reviewed prior to every release or update.
2B-1.2 Examine written software-development procedures and interview responsible personnel to verify the application vendor performs reviews for all application code changes and non-code configuration mechanisms as follows:
Reviews are performed by an individual, other than the code author, who is …
Modified
p. 26 → 155
Processes must include the following:
Removed
p. 27
Describe how code review results for the sample of code changes verified that code reviews ensure code is developed according to secure coding guidelines:
2B-1.2.3 Examine change control documentation for a sample of code changes to verify that appropriate corrections are implemented prior to release. Change control documentation reviewed: <Report Findings Here> 2B-1.2.4 Review and approval of review results by management prior to release.
2B-1.2.4 Examine change control documentation for a sample of code changes to verify that review results are reviewed and approved by management prior to release.
2B-1.3.a Obtain and examine the developer’s change-control procedures for software modifications, and verify that the procedures require the following:
Documentation of customer impact Documented approval of change by appropriate authorized parties Functionality testing to verify that the change does not adversely impact the security of the device Back-out or application de-installation procedures Documented developer change-control procedures for software modifications <Report Findings …
2B-1.2.3 Examine change control documentation for a sample of code changes to verify that appropriate corrections are implemented prior to release. Change control documentation reviewed: <Report Findings Here> 2B-1.2.4 Review and approval of review results by management prior to release.
2B-1.2.4 Examine change control documentation for a sample of code changes to verify that review results are reviewed and approved by management prior to release.
2B-1.3.a Obtain and examine the developer’s change-control procedures for software modifications, and verify that the procedures require the following:
Documentation of customer impact Documented approval of change by appropriate authorized parties Functionality testing to verify that the change does not adversely impact the security of the device Back-out or application de-installation procedures Documented developer change-control procedures for software modifications <Report Findings …
Modified
p. 27 → 37
Solution provider’s documentation reviewed: <Report Findings Here> 1D-1.2.1 All new installations and updates of applications must be cryptographically authenticated by the POI device’s firmware.
Modified
p. 27 → 181
Sample of systems reviewed: <Report Findings Here> Documentation reviewed: <Report Findings Here> Describe how the observed system configurations observed verified that:
Modified
p. 27 → 198
<Report Findings Here> 2B-1.2.3 Confirming that appropriate corrections are implemented prior to release.
<Report Findings Here> 6G-3.2.9.3 Continuous or motion-activated, appropriate lighting must be provided for the cameras.
Modified
p. 27 → 266
Processes must include the following:
Removed
p. 28
<Report Findings Here> 2B-1.3.2 Documented approval of change by appropriate authorized parties 2B-1.3.2 Verify that documented approval by appropriate authorized parties is present for each change. Identify the P2PE Assessor who verified that, for each change examined, this was documented according to the change-control procedures:
2B-1.3.3.a For each sampled change, verify that functionality testing was performed to verify that the change does not adversely impact the security of the device.
<Report Findings Here> 2B-1.3.3.b Verify that all changes (including patches) are tested per secure coding guidance before being released. Identify the P2PE Assessor who verified that, for each change examined, this was documented according to the change-control procedures:
2B-1.3.4 Verify that back-out, rollback, or application de-installation procedures are prepared for each change. Identify the P2PE Assessor who verified that, for each change examined, this was documented according to the change-control procedures:
Developing with least privilege.
Developing with fail-safe exception handling.
Developing with defensive …
2B-1.3.3.a For each sampled change, verify that functionality testing was performed to verify that the change does not adversely impact the security of the device.
<Report Findings Here> 2B-1.3.3.b Verify that all changes (including patches) are tested per secure coding guidance before being released. Identify the P2PE Assessor who verified that, for each change examined, this was documented according to the change-control procedures:
2B-1.3.4 Verify that back-out, rollback, or application de-installation procedures are prepared for each change. Identify the P2PE Assessor who verified that, for each change examined, this was documented according to the change-control procedures:
Developing with least privilege.
Developing with fail-safe exception handling.
Developing with defensive …
Modified
p. 28 → 36
<Report Findings Here> 2B-1.3.4 Back-out, rollback, or application de-installation procedures.
<Report Findings Here> 1C-2.1.3 Require dual control for the application-signing process.
Modified
p. 28 → 46
<Report Findings Here> 2B-1.4 Applications must be developed according to industry best practices for secure coding techniques, including (but not limited to):
<Report Findings Here> 3A-2.2 Processes must be implemented to ensure P2PE controls are maintained when changes to the P2PE solution occur including, but not limited to:
Modified
p. 28 → 68
<Report Findings Here> 2B-1.3.3 Functionality testing to verify that the change does not adversely impact the security of the device.
<Report Findings Here> 5B-1.7 Processes are implemented to ensure that clear-text account data is never sent back to the encryption environment.
Modified
p. 28 → 139
Identify the P2PE Assessor who verified that, for each change examined, this was documented according to the change-control procedures:
Identify the P2PE Assessor who confirms that tamper-evident packaging prevents the determination of the key component without visible damage to the packaging:
Removed
p. 29
Developing with defensive (protective) techniques regarding the logical input interfaces of the application.
Developing with fail-safe defaults.
2B-1.4.1.a Obtain and review software development processes for applications.
Verify the process includes prevention of common coding vulnerabilities relevant to the programming languages and platforms in use.
Documented software processes reviewed: <Report Findings Here> 2B-1.4.1.b Verify that applications are not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit vulnerabilities relevant to the application (an example of such a vulnerability would include buffer overflows).
Describe how manual or automated penetrating testing performed verified that applications are not vulnerable to common coding vulnerabilities:
<Report Findings Here> 2B-1.4.2 Application risk-assessment techniques (e.g., (application threat-modeling) must be used to identify potential application-security design flaws and vulnerabilities during the software-development process. Risk-assessment processes include the following:
Coverage of all functions of the application, including but not limited to, security-impacting features and features that …
Developing with fail-safe defaults.
2B-1.4.1.a Obtain and review software development processes for applications.
Verify the process includes prevention of common coding vulnerabilities relevant to the programming languages and platforms in use.
Documented software processes reviewed: <Report Findings Here> 2B-1.4.1.b Verify that applications are not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit vulnerabilities relevant to the application (an example of such a vulnerability would include buffer overflows).
Describe how manual or automated penetrating testing performed verified that applications are not vulnerable to common coding vulnerabilities:
<Report Findings Here> 2B-1.4.2 Application risk-assessment techniques (e.g., (application threat-modeling) must be used to identify potential application-security design flaws and vulnerabilities during the software-development process. Risk-assessment processes include the following:
Coverage of all functions of the application, including but not limited to, security-impacting features and features that …
Modified
p. 29 → 173
Responsible personnel interviewed: <Report Findings Here> Describe how the certificate issuing and replacement processes observed verified that:
Removed
p. 30
Coverage of all functions of the application, including but not limited to, security-impacting features and features that cross trust boundaries.
Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
Implementation of appropriate corrections and countermeasures during the development process.
Documentation of application risk-assessment results for management review and approval.
Identification of all areas within applications that interact with account data, as well as any process-oriented outcomes that could lead to the exposure of account data.
A list of potential threats and vulnerabilities resulting from account-data flow analyses, and assigned risk ratings (e.g., high, medium, or low priority) to each.
Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.).
Managing sensitive data in memory.
Security testing (e.g., penetration testing techniques).
Risk-assessment techniques.
Note: Training for application developers may be provided in-house or by …
Assessment of application decision points, process flows, data flows, data storage, and trust boundaries.
Implementation of appropriate corrections and countermeasures during the development process.
Documentation of application risk-assessment results for management review and approval.
Identification of all areas within applications that interact with account data, as well as any process-oriented outcomes that could lead to the exposure of account data.
A list of potential threats and vulnerabilities resulting from account-data flow analyses, and assigned risk ratings (e.g., high, medium, or low priority) to each.
Secure coding techniques to avoid common coding vulnerabilities (e.g., vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.).
Managing sensitive data in memory.
Security testing (e.g., penetration testing techniques).
Risk-assessment techniques.
Note: Training for application developers may be provided in-house or by …
Modified
p. 30 → 37
• changed application or a
Modified
p. 30 → 90
Responsible personnel interviewed: <Report Findings Here> 2B-1.5 Application vendor must provide training in secure development practices to application developers, as applicable for the developer’s job function and technology used, e.g.:
Responsible personnel interviewed: <Report Findings Here> 5D-4.4 Dual access must be required for the secure room housing the Host System.
Modified
p. 30 → 97
Identify training materials examined: <Report Findings Here>
Identify reports reviewed: <Report Findings Here>
Modified
p. 30 → 231
Documented software development processes reviewed: <Report Findings Here> 2B-1.5.b Interview a sample of developers to verify that they are knowledgeable in secure development practices and coding techniques, as applicable to the technology used.
Documented procedures reviewed: <Report Findings Here> 6D-2.3 Observe key-loading processes to verify that the loading process results in one of the following:
Removed
p. 31
Sample of developers interviewed: <Report Findings Here> 2B-1.6 Secure source-control practices must be implemented to verify integrity of source-code during the development process.
<Report Findings Here> 2B-1.7 The application vendor must document and follow a software-versioning methodology as part of their system-development lifecycle. The methodology must follow the procedures in the P2PE Program Guide for changes to payment applications and include at least the following:
2B-1.7.a Examine documented software-development processes to verify they include the application vendor’s versioning methodology, and that the versioning methodology must be in accordance with the P2PE Program Guide.
Verify that the documented versioning methodology is required to be followed for the application, including all changes to the application.
Details of how the elements of the version scheme are in accordance with requirements specified in the P2PE Program Guide.
The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric …
<Report Findings Here> 2B-1.7 The application vendor must document and follow a software-versioning methodology as part of their system-development lifecycle. The methodology must follow the procedures in the P2PE Program Guide for changes to payment applications and include at least the following:
2B-1.7.a Examine documented software-development processes to verify they include the application vendor’s versioning methodology, and that the versioning methodology must be in accordance with the P2PE Program Guide.
Verify that the documented versioning methodology is required to be followed for the application, including all changes to the application.
Details of how the elements of the version scheme are in accordance with requirements specified in the P2PE Program Guide.
The format of the version scheme, including number of elements, separators, character set, etc. (consisting of alphabetic, numeric, and/or alphanumeric …
Modified
p. 31 → 63
Documented software development procedures reviewed: <Report Findings Here> Responsible personnel interviewed: <Report Findings Here> 2B-1.6.b Examine mechanisms and observe procedures for securing source- code to verify integrity of source-code is maintained during the development process.
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here> 5A-1.1.1 The approval listing must match the deployed devices in the following characteristics:
Modified
p. 31 → 67
Documented software development procedures reviewed: <Report Findings Here> 2B-1.7.1 The vendor’s software versioning methodology must define the specific version elements used, including at least the following:
Documented policies and procedures reviewed: <Report Findings Here> 5B-1.4.b Verify documented procedures are defined for the following:
Modified
p. 31 → 133
Describe how mechanisms and procedures for securing source-code verified that integrity of source-code is maintained during the development process:
Describe how the observed processes for generating and loading keys into production systems verified that they are in no way associated with test or development keys:
Modified
p. 31 → 143
6F-3.1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible key-calculation methods.
Removed
p. 32
Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
Specific identification and definition of changes that:
Specific identification and definition of changes that:
- Have no impact on functionality of the application or its dependencies
- Have no impact on functionality of the application or its dependencies
- Have impact on application functionality but no impact on security or P2PE requirements
- Have impact on application functionality but no impact on security or P2PE requirements
- Have impact to any security functionality or P2PE requirement.
- Have impact to any security functionality or P2PE requirement.
How each type of change ties to a specific version number.
How each type of change ties to a specific version number.
Documented versioning …
Description of all types and impacts of application changes (e.g., changes that have no impact, low impact, or high impact to the application).
Specific identification and definition of changes that:
Specific identification and definition of changes that:
- Have no impact on functionality of the application or its dependencies
- Have no impact on functionality of the application or its dependencies
- Have impact on application functionality but no impact on security or P2PE requirements
- Have impact on application functionality but no impact on security or P2PE requirements
- Have impact to any security functionality or P2PE requirement.
- Have impact to any security functionality or P2PE requirement.
How each type of change ties to a specific version number.
How each type of change ties to a specific version number.
Documented versioning …
Modified
p. 32 → 30
1B-3.2.a Examine documented procedures to verify they include:
Modified
p. 32 → 48
Personnel interviewed: <Report Findings Here> 3A-3.3 The solution provider must maintain a record of all suspicious activity, to include the following:
Modified
p. 32 → 79
Documented procedures reviewed: <Report Findings Here> Personnel interviewed: <Report Findings Here>
Modified
p. 32 → 176
<Report Findings Here> 2B-1.8.c Interview personnel and observe processes for each type of change to verify that the documented methodology is being followed for all types of changes.
Documented procedures reviewed: <Report Findings Here> 6F-2.7.1.b Interview responsible personnel and observe process to verify that in the event a compromise is known or suspected:
Modified
p. 32 → 235
Personnel interviewed: <Report Findings Here> Describe processes observed that verified that the documented methodology is being followed for all types of changes:
Personnel interviewed: <Report Findings Here> Describe how observation of the facilities verified that:
Removed
p. 33
Details of how wildcards are used in the versioning methodology.
Details of how wildcards are used in the versioning methodology.
Wildcards are never used for any change that has an impact on the security of the application and/or the POI device.
Wildcards are never used for any change that has an impact on the security of the application and/or the POI device.
Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.
Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a wildcard element must not be used to represent security-impacting changes.
Note: Wildcards may only be used in accordance with the P2PE Program Guide.
Any element of the version number used to represent a non-security- impacting change (including a wildcard element) must never be …
Details of how wildcards are used in the versioning methodology.
Wildcards are never used for any change that has an impact on the security of the application and/or the POI device.
Wildcards are never used for any change that has an impact on the security of the application and/or the POI device.
Any element of the version number used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change.
Wildcard elements must not precede version elements that could represent security-impacting changes. Any version elements that appear after a wildcard element must not be used to represent security-impacting changes.
Note: Wildcards may only be used in accordance with the P2PE Program Guide.
Any element of the version number used to represent a non-security- impacting change (including a wildcard element) must never be …
Modified
p. 33 → 32
1B-5.1.a Examine device and/or system configurations to verify that any changes to the critical functions of the POI devices are logged, including:
Modified
p. 33 → 57
<Report Findings Here> Sample of recent payment applications reviewed: <Report Findings Here>
<Report Findings Here> Data flows reviewed: <Report Findings Here>
Modified
p. 33 → 194
Personnel interviewed: <Report Findings Here> Describe processes observed that verified that wildcards are never used for any change that has an impact on security or any P2PE requirements and that elements of the version number used to represent non-security-impacting changes (including a wildcard element) are never be used to represent a security impacting change:
Personnel interviewed: <Report Findings Here> Describe how the observation of operations verified that the Level 3 secure room is not used for any business activity other than certificate operations:
Modified
p. 33 → 272
Identify the P2PE Assessor who confirms that any use of wildcards documented versioning methodology is in accordance with the P2PE Program <Report Findings Here> 2B-1.9.c Interview personnel and observe processes for each type of change to verify that:
Identify the P2PE Assessor who confirms that the secure area is only accessed through a solid-core or a steel door, with door hinges that cannot be removed from outside of the room:
Removed
p. 34
Wildcards are not used for any change that has an impact on security or any P2PE requirements.
Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change.
2B-1.10 Verify the application’s Implementation Guide required at 2C-3 of this document includes a description of the vendor’s published versioning methodology for customers and integrators/resellers, and includes the following:
Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.) Details of how security-impacting changes will be indicated by the version Details of how other types of changes will affect the version Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-1.10:
<Report Findings …
Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change.
2B-1.10 Verify the application’s Implementation Guide required at 2C-3 of this document includes a description of the vendor’s published versioning methodology for customers and integrators/resellers, and includes the following:
Details of versioning scheme, including the format of the version scheme (number of elements, separators, character set, etc.) Details of how security-impacting changes will be indicated by the version Details of how other types of changes will affect the version Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-1.10:
<Report Findings …
Modified
p. 34 → 68
Supporting documentation reviewed: <Report Findings Here> 5B-1.6 Decryption environment must be secured according to PCI DSS.
Modified
p. 34 → 115
Responsible personnel interviewed: <Report Findings Here> Describe how the process for conveying public keys verified that self-signed certificates are not used as the sole method of authentication:
Modified
p. 34 → 177
Documented software development processes reviewed: <Report Findings Here> 2B-1.12.b Interview software developers and observe processes to verify that application updates are reviewed for conformity with the versioning methodology prior to release.
Documented procedures reviewed: <Report Findings Here> 6F-2.7.4.b Interview responsible personnel to verify that the following procedures are performed in the event a compromise:
Removed
p. 35
Signature by an authorized party to formally approve release of the application or application update.
Confirmation that secure development processes were followed by the vendor.
2B-1.13.a Examine documented processes to verify that final release of the application and any application updates are formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all SDLC processes were followed.
Formal approval and signature by an authorized party.
Confirmation that that all secure development processes were followed.
Sample of recent releases of application and application updates <Report Findings Here> Approval documentation reviewed: <Report Findings Here> 2B-2.1 Where the application relies on the Open Protocol functionality of the POI device firmware, the application must be developed in accordance with the POI device vendor's security guidance.
Note: POI device vendor security guidance is intended for application developers, system integrators, and end-users of the platform to meet requirements in …
Confirmation that secure development processes were followed by the vendor.
2B-1.13.a Examine documented processes to verify that final release of the application and any application updates are formally approved and documented, including a signature by an authorized party to formally approve the release and confirmation that all SDLC processes were followed.
Formal approval and signature by an authorized party.
Confirmation that that all secure development processes were followed.
Sample of recent releases of application and application updates <Report Findings Here> Approval documentation reviewed: <Report Findings Here> 2B-2.1 Where the application relies on the Open Protocol functionality of the POI device firmware, the application must be developed in accordance with the POI device vendor's security guidance.
Note: POI device vendor security guidance is intended for application developers, system integrators, and end-users of the platform to meet requirements in …
Modified
p. 35 → 168
Documented processes reviewed: <Report Findings Here> 2B-1.13.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes:
Documented processes reviewed: <Report Findings Here> 6E-3.8 POI private keys must not be shared between devices.
Removed
p. 36
Note: The PTS POI Open Protocols module ensures that open protocols and services in POI devices do not have vulnerabilities that can be remotely exploited and yield access to sensitive data or resources in the device. The POI device vendor defines what protocols and services are supported by the device and provides guidance to their use.
Adding or enabling additional services or protocols, or failing to follow the issued POI device vendor’s security guidance will invalidate the approval status of that device for that implementation.
2B-2.1.1. Perform a source-code review and verify that the application:
Was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols.
Does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device's vendor security guidance. This includes the use of: o Link Layer protocols o …
Adding or enabling additional services or protocols, or failing to follow the issued POI device vendor’s security guidance will invalidate the approval status of that device for that implementation.
2B-2.1.1. Perform a source-code review and verify that the application:
Was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols.
Does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device's vendor security guidance. This includes the use of: o Link Layer protocols o …
Modified
p. 36 → 23
Link Layer protocols IP protocols Security protocols IP services
Link Layer Protocols IP Protocols Security Protocols IP Services
Modified
p. 36 → 37
Following vendor guidance in the application’s Implementation Guide.
Modified
p. 36 → 196
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-2.2.a:
Identify the P2PE Assessor who confirms the dual-occupancy requirements are managed using electronic systems:
Removed
p. 37
Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that any connections to, or use of, shared resources are handled securely and in accordance with the POI device vendor’s security guidance.
<Report Findings Here> 2B-2.3 Applications do not bypass or render ineffective any application segregation that is enforced by the POI device.
2B-2.3 Perform a source-code review and verify that applications do not bypass or render ineffective any application segregation that is enforced by the POI device, in accordance with the POI device vendor’s security guidance.
Describe how the source-code review verified that applications do not bypass or render ineffective any application segregation that is enforced by the POI <Report Findings Here> 2B-2.4 Applications do not bypass or render ineffective any OS hardening implemented by the POI device.
2B-2.4 Perform a …
<Report Findings Here> 2B-2.3 Applications do not bypass or render ineffective any application segregation that is enforced by the POI device.
2B-2.3 Perform a source-code review and verify that applications do not bypass or render ineffective any application segregation that is enforced by the POI device, in accordance with the POI device vendor’s security guidance.
Describe how the source-code review verified that applications do not bypass or render ineffective any application segregation that is enforced by the POI <Report Findings Here> 2B-2.4 Applications do not bypass or render ineffective any OS hardening implemented by the POI device.
2B-2.4 Perform a …
Removed
p. 38
2B-3.1 Through observation and review of the application developer’s system development documentation, confirm the application developer’s process includes full documentation and integration testing of the application and intended platforms, including the following:
Application developer’s system development documentation reviewed: <Report Findings Here> 2B-3.1.1 The application developer must provide key-management security guidance describing how cryptographic keys and certificates have to be used.
Examples of guidance include which cryptographic certificates to load, how to load account-data keys (through the firmware of the device), when to roll keys, etc.
2B-3.1.1 Review the application’s Implementation Guide required at 2C-3 of this document, and confirm it includes key-management security guidance for solution providers, describing how cryptographic keys and certificates have to be used and managed.
<Report Findings Here> 2B-3.1.2 The application developer must perform final integration testing on the device, which includes identification and correction of any residual vulnerabilities stemming from the integration with the vendor’s platform.
2B-3.1.2 Interview application developers …
Application developer’s system development documentation reviewed: <Report Findings Here> 2B-3.1.1 The application developer must provide key-management security guidance describing how cryptographic keys and certificates have to be used.
Examples of guidance include which cryptographic certificates to load, how to load account-data keys (through the firmware of the device), when to roll keys, etc.
2B-3.1.1 Review the application’s Implementation Guide required at 2C-3 of this document, and confirm it includes key-management security guidance for solution providers, describing how cryptographic keys and certificates have to be used and managed.
<Report Findings Here> 2B-3.1.2 The application developer must perform final integration testing on the device, which includes identification and correction of any residual vulnerabilities stemming from the integration with the vendor’s platform.
2B-3.1.2 Interview application developers …
Modified
p. 38 → 139
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2B-3.1.1:
Identify the P2PE Assessor who confirms that for each key component storage container:
Removed
p. 39
<Report Findings Here> 2C-1.1 Software developers must establish and implement a process to identify and test their applications for security vulnerabilities and implementation errors prior to every release (including updates or patches) using manual or automated vulnerability assessment processes.
2C-1.1.a Obtain and examine processes to identify new vulnerabilities and test applications for vulnerabilities that may affect the application. Verify the processes include the following:
Using outside sources for security vulnerability information.
Periodic testing of applications for new vulnerabilities.
New vulnerabilities are identified using outside sources of security vulnerability information.
All applications are tested for vulnerabilities.
Responsible software vendor personnel interviewed: <Report Findings Here> 2C-1.2 Software vendors must establish and implement a process to develop and deploy critical security updates to address discovered security vulnerabilities in a timely manner.
2C-1.2.a Obtain and examine processes to develop and deploy application security upgrades. Verify that processes include the timely development and deployment of critical security updates …
2C-1.1.a Obtain and examine processes to identify new vulnerabilities and test applications for vulnerabilities that may affect the application. Verify the processes include the following:
Using outside sources for security vulnerability information.
Periodic testing of applications for new vulnerabilities.
New vulnerabilities are identified using outside sources of security vulnerability information.
All applications are tested for vulnerabilities.
Responsible software vendor personnel interviewed: <Report Findings Here> 2C-1.2 Software vendors must establish and implement a process to develop and deploy critical security updates to address discovered security vulnerabilities in a timely manner.
2C-1.2.a Obtain and examine processes to develop and deploy application security upgrades. Verify that processes include the timely development and deployment of critical security updates …
Modified
p. 39 → 30
Note: A “critical security update” is one that addresses an imminent risk to account data.
Note: A “critical software security update” is one that addresses an imminent risk to account data, either directly or indirectly.
Modified
p. 39 → 38
Responsible software vendor personnel interviewed: <Report Findings Here> 2C-2.1 Ensure that all application installations and updates are cryptographically authenticated as follows:
Responsible personnel interviewed: <Report Findings Here> Describe how the installation and update processes observed verified that new application installations and updates are cryptographically authenticated by the POI device’s firmware:
Modified
p. 39 → 167
Documented processes reviewed: <Report Findings Here> 2C-1.1.b Interview responsible software vendor personnel to confirm the following:
Documented procedures reviewed: <Report Findings Here> 6E-2.5.b Interview responsible personnel and observe KDH configurations to verify that:
Modified
p. 39 → 176
Documented processes reviewed: <Report Findings Here> 2C-1.2.b Interview responsible software-vendor personnel to confirm that application security updates are developed and critical security updates are deployed in a timely manner.
Documented procedures reviewed: <Report Findings Here> 6F-2.7.b Interview responsible personnel to verify that the defined mechanisms to respond to compromise of a CA are in place and include:
Removed
p. 40
A description of how the application is cryptographically authenticated using the approved security mechanisms of the POI device’s firmware for any application installations and updates.
Instructions for how to use the approved security mechanisms to perform application installations and updates.
A statement that application installations and updates cannot occur except by using the approved security mechanisms of the POI device’s firmware.
<Report Findings Here> 2C-2.1.1.b Perform a source-code review to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.
Describe how the source-code review verified that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware:
<Report Findings Here> 2C-2.1.1.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that, by following the Implementation Guide, the application …
Instructions for how to use the approved security mechanisms to perform application installations and updates.
A statement that application installations and updates cannot occur except by using the approved security mechanisms of the POI device’s firmware.
<Report Findings Here> 2C-2.1.1.b Perform a source-code review to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.
Describe how the source-code review verified that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware:
<Report Findings Here> 2C-2.1.1.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that, by following the Implementation Guide, the application …
Modified
p. 40 → 38
A statement that all applications must be signed via the instructions provided in the Implementation Guide.
Cryptographic signing processes for applications are followed as specified in the Implementation Guide.
Modified
p. 40 → 93
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-2.1.2:
Identify the P2PE Assessor who confirms all windows in the observed secure room are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room:
Modified
p. 40 → 250
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-2.1.1.a:
Identify the P2PE Assessor who confirms that for each key component storage container:
Removed
p. 41
2C-3.1.1 Verify the Implementation Guide covers all related requirements in P2PE Domain 2. Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-3.1.1:
Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements. Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-3.1.2.a:
<Report Findings Here> 2C-3.1.3 Distribution to all new and existing application installers (e.g., solution providers, integrator/resellers, etc.), and re-distribution to all existing application installers every time the guide is updated.
2C-3.1.3 Verify the Implementation Guide is distributed to new application installers, and re-distributed to all application installers every time the guide is updated.
<Report Findings Here> 2C-3.2 Develop and …
Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
Any changes to the application (e.g., device changes/upgrades and major and minor software changes).
2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements. Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-3.1.2.a:
<Report Findings Here> 2C-3.1.3 Distribution to all new and existing application installers (e.g., solution providers, integrator/resellers, etc.), and re-distribution to all existing application installers every time the guide is updated.
2C-3.1.3 Verify the Implementation Guide is distributed to new application installers, and re-distributed to all application installers every time the guide is updated.
<Report Findings Here> 2C-3.2 Develop and …
Modified
p. 41 → 37
Any changes to the Implementation Guide requirements in this document.
All Implementation Guide requirements were followed.
Modified
p. 41 → 53
- Any changes to the P2PE requirements.
Modified
p. 41 → 54
PIM is reviewed at least annually and upon changes to the solution or changes to the PCI P2PE requirements PIM is updated as needed to keep the document current with:
Modified
p. 41 → 128
Documented processes for dissemination reviewed: <Report Findings Here> 2C-3.1.1 Addresses all requirements in P2PE Domain 2 wherever the Implementation Guide is referenced.
Documented procedures reviewed: <Report Findings Here> 6D-3.1.b Observe key-loading environments and controls to verify the following:
Modified
p. 41 → 139
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-3.1.3:
Identify the P2PE Assessor who confirms that start-up instructions and other notes used by service technicians do not contain initialization- key values written in the clear:
Modified
p. 41 → 141
<Report Findings Here> 2C-3.1.2.b Verify the Implementation Guide is updated as needed to keep the documentation current with:
<Report Findings Here> 6F-2.1.4.b Verify notifications include the following:
Modified
p. 41 → 250
Identify the P2PE Assessor who confirms that the application’s Implementation Guide includes all details for 2C-3.1.2.b:
Identify the P2PE Assessor who confirms that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear:
Modified
p. 42 → 213
Documentation reviewed: <Report Findings Here>