• Tweet

• Tweet

P2PE Domain 2

Application Security :

Secure Read and Exchange of Data (SRED) – Enables cardholder data to be secured or protected (i.e. truncation) after being read by the PTS terminal. It then enables the secured cardholder data to be transmitted from the terminal. – Secure first step for Point to Point or end to end encryption
When used in a P2PE solution, all software (excluding the PCI-approved POI firmware) implemented on the POI device that has the potential to access clear-text account data (P2PE applications) must be assessed and confirmed to be secure as per Domain 2 requirements.

Glossary first:

PIM template: P2PE Instruction Manual template

PTS : Pin Transaction security

DSS: Data Security Standards

WEP: Wired Equivalent Privacy

TLS: Transport Layer Security

QSA: Qualified Security Assessor

ASV:  Approved Scanning Vendor

CDE: cardholder data environment

HSM : Hardware security module
2A Protect PAN and SAD (Sensitive authentication data)
2A-1 The application executes on a PCI-approved POI device with SRED(Secure Read and Exchange of Data ) enabled and active.
1.1: The application must only use the PTS SRED-validated account-data capture mechanisms of the underlying POI device for accepting and processing P2PE transactions.
2A-2 The application does not store PAN and/or SAD for any longer than business processes require.
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.
2.2: The application must not store PAN and/or SAD (even if encrypted). Note: Storage of encrypted PAN data is acceptable during the business process of finalizing the payment transaction if needed (e.g., offline transactions). However, at all times, SAD is not stored after authorization is complete.
2.3: The application must not retain PAN and/or SAD in working memory any longer than strictly necessary
2.4: The application must securely delete any PAN and/or SAD stored during application processing
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.
3.1: The application must not output clear-text account data outside of the POI device.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: -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. -text PAN after completion of printing.
3.2: The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications.

Note: The application is allowed to share clear-text account data directly with the POI device’s SRED approved firmware.
3.3: The application must only use external communication methods included in the PCI-approved POI device evaluation. For example, the POI device may provide an IP stack approved per the PTS(Pin Transaction Security) 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.
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.
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:
1.1.1: Live PANs must not be used for testing or development.
1.1.2: Development, test, and/or custom application data/accounts, user IDs, and passwords must be removed before applications are released for production or released to customers.

1.2: Application code and any non-code configuration mechanisms must be reviewed prior to every release or update
1.3: All changes to the application must follow change-control procedures.
1.3.1: Documentation of impact
1.3.2: Documented approval of change by appropriate authorized parties
1.3.3: Functionality testing to verify that the change does not adversely impact the security of the device.
1.4: Applications must be developed according to industry best practices for secure coding techniques, including (but not limited to): e. -safe exception handling.
.
1.4.1: Application development processes must include prevention of common coding vulnerabilities. Example:

int risky_programming(char *input){ char str[1000+1]; // one more for the null character // … strcpy(str, input); // copy input // … }
int secure_programming(char *input){ char str[1000]; // … strncpy(str, input, sizeof(str)); // copy input without exceeding the length of the destination str[sizeof(str) – 1] = ‘\0’; // if strlen(input) >= sizeof(str) then strncpy won’t NUL terminate // … }
1.4.2: Application risk-assessment processes include the following:
-impacting features and
features that cross trust boundaries.
d trust boundaries.
oriented outcomes that could lead to the exposure of account data. from account-data flow analyses and assigned risk ratings (e.g., high, medium, or low priority) to each.

-assessment results for management review and approval.
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. Examples of how training may be delivered include on-the-job, instructor-led, and computer-based.
1.6: Secure source-control practices must be implemented to verify integrity of source-code during the development process.
1.7: The application vendor must document and follow a software-versioning methodology as part of their systemdevelopment lifecycle in accordance with requirements specified in the P2PE Program Guide. The versioning methodology and the P2PE Application Implementation Guide must fully describe the format of the application version number including the following:
for each element

version scheme
umber used to represent a non-security-impacting change (including a wildcard element) must never be used to represent a security impacting change. -impacting changes. Any version elements that appear after a wildcard element must not be used to represent security-impacting changes
2B-2 The application is implemented securely, including the secure use of any resources shared between different applications.
2B-3 The application vendor uses secure protocols, provides guidance on their use, and performs integration testing on the final application.
3.1.1: The application developer must provide key-management security guidance describing how cryptographic keys and certificates have to be used
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. The application may provide additional encryption to existing SRED encryption, but cannot bypass or replace SRED encryption.
2C Implement secure application-management processes.
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 PCI-approved POI device.
2C-3 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.
3.1: The process to develop, maintain, and disseminate an Implementation Guide for the application’s installation, maintenance, upgrades and general use.

Points to remember:

The use of WEP as a security control is prohibited.

Merchants and other entities that store, process and/or transmit cardholder data must comply with PCI DSS.

SSL and early TLS are no longer considered to be strong cryptography and cannot be used as a security control after June 30, 2016.

Point-of-sale (POS) devices that can be verified as not being susceptible to all known exploits for SSL and early TLS may continue using these protocols as a security control after 30 June 2016. But whenever possible, move on to the next security protocol. It’s always better to exceed PCI requirement than to have something open to interpretation in the event of a breach.

Do mobile wallets need to be PCI – DSS compliant?