PCI Security Standard Council
For more information on the latest version of PCI-DSS and PA-DSS
Introduction
AppSec Labs services cover the below specified PCI DSS and PA-DSS requirements. Our services include secure coding courses, advanced penetration testing, consultancy and remediation assistance.
PCI-DSS – Private Card Industry Digital Security Standard for organizations involved in processing PCI data. It is a comprehensive standard covering security in infrastructure, methodology and the applications processing PCI data.
The Payment Application Data Security Standard (PA-DSS) is the global security standard created by the Payment Card Industry Security Standards Council (PCI SSC). This standard mainly focuses on specifying application-level requirements such as coding and application development methodologies.
Use of a PA-DSS compliant application by itself does not make an entity PCI DSS compliant, since the application must be implemented into a PCI-DSS compliant environment and this must be done according to the PA-DSS Implementation Guide provided by the payment application vendor.
Who is Subject to PCI-DSS
Any application that stores, processes or transmits cardholder data is in scope for a PCI DSS assessment, including applications that have been validated to PA-DSS. The PCI DSS assessment should verify the PA-DSS validated payment application is properly configured and securely implemented per PCI DSS requirements. If the payment application has undergone any customization, a more in-depth review will be required during the PCI DSS assessment, as the application may no longer be representative of the version that was validated to PA-DSS.
Additional information and related links
AppSec Labs – Training
| Requirement | PCI DSS ID | PA DSS ID | Relevant AppSec Labs Courses |
|---|---|---|---|
| Provide training in secure development practices for application developers, as applicable for the developer’s job function and technology used, for example: • Secure application design • Secure coding techniques to avoid common coding vulnerabilities (for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.) • Managing sensitive data in memory Code reviews • Security testing (for example, penetration testing techniques) • Risk-assessment techniques | 6.5 | 5.1.7 | • Secure Coding • Application Security for Designers / Architects • Application Security for QA |
| Educate personnel upon hire and at least annually | 12.6.1 | • Security Awareness • Best Practices • Secure Coding |
AppSec Labs – SDLC Consultancy
| Requirement | PCI-DSS ID | PA-DSS ID |
|---|---|---|
| Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage: • Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements • Processes for secure deletion of data when no longer needed • Specific retention requirements for cardholder data • A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention | 3.1 | 2.1 |
| Examine written software-development processes to verify that the processes are based on industry standards and/or best practices. | 6.3.a | 5.1.a |
| For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks. Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes either manual or automated vulnerability security assessment tools or methods—as follows: – At least annually – After any changes – By an organization that specializes in application security – That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment – That all vulnerabilities are corrected – That the application is re-evaluated after the corrections. | 6.6 | 5.1.4 |
| Implement a methodology for penetration testing that includes the following: Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5 | 11.3 | |
| Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections. | 11.3.3 |
AppSec Labs – Grey Box Testing
| Requirement | PCI-DSS ID | PA-DSS ID |
|---|---|---|
| Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage: • Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements • Processes for secure deletion of data when no longer needed • Specific retention requirements for cardholder data • A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention | 3.1 | 2.1 |
| Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process. Sensitive authentication data is collected only when needed to solve a specific problem. • Such data is stored in a specific, known location with limited access. • The minimum amount of data is collected as needed to solve a specific problem. • Sensitive authentication data is encrypted with strong cryptography while stored. • Data is securely deleted immediately after use, including from: – Log files – Debugging files – Other data sources received from customers | 3.2 | 1.1 / 1.1.4 |
| Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card not-present transactions | 3.2.3 | 1.1.3 |
| Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: • One-way hashes based on strong cryptography, (hash must be of the entire PAN) • Truncation (hashing cannot be used to replace the truncated segment of PAN) • Index tokens and pads (pads must be securely stored) • Strong cryptography with associated key-management processes and procedures. | 3.4 | 2.3 |
| Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times: • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data encrypting key • Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device) • As at least two full-length key components or key shares, in accordance with an industry accepted method | 3.5.2 | 2.4 |
| Secure cryptographic key storage | 3.6.3 | 2.5 / 2.6 |
| Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: • In accordance with PCI DSS Based on industry standards and/or best practices. • Incorporating information security throughout the software-development life cycle | 6.3 | 5.1 |
| Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. | 6.3.1 | 5.1.3 |
| Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: • Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices. • Code reviews ensure code is developed according to secure coding guidelines • Appropriate corrections are implemented prior to release. Code-review results are reviewed and approved by management prior to release. | 6.3.2 | 5.1.4 |
| Insecure cryptographic storage • Prevent cryptographic flaws. • Use strong cryptographic algorithms and keys. | 6.5.3 | 5.2.3 |
AppSec Labs – Black Box Penetration Testing
| Requirement | PCI-DSS ID | PA-DSS ID |
|---|---|---|
| Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following: • Only trusted keys and certificates are accepted. • The protocol in use only supports secure versions or configurations. The encryption strength is appropriate for the encryption methodology in use. | 4.1 | 6.2 |
| Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. | 6.5.1 | 5.2.1 |
| Insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications | 6.5.4 | 5.2.4 |
| Improper error handling is addressed by coding techniques that do not leak information via error messages (for example, by returning generic rather than specific error details | 6.5.5 | 5.2.5 |
| Cross-site scripting (XSS) • Validating all parameters before inclusion • Utilizing context-sensitive escaping. | 6.5.7 | 5.2.7 |
| Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions). Validate: • Proper authentication of users • Sanitizing input • Not exposing internal object references to users User interfaces that do not permit access to unauthorized functions. | 6.5.8 | 5.2.8 |
| Cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers | 6.5.9 | 5.2.9 |
| Broken authentication and session management. Presence of coding techniques that commonly include: • Flagging session tokens (for example cookies) as “secure” • Not exposing session IDs in the URL Incorporating appropriate time-outs and rotation of session IDs after a successful login. | 6.5.10 | 5.2.10 |
| If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session. | 8.1.8 | 3.1.11 |
| Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. | 8.2.1 | 3.3 |
| For a sample of system components, examine data transmissions to verify that passwords are unreadable during transmission. | 8.2.1c | 3.3.1a |
| Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys. | 8.2.2 | 3.1 |
| Passwords/phrases must meet the following: • Require a minimum length of at least seven characters. • Contain both numeric and alphabetic characters. Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above. | 8.2.3a | |
| Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used. | 8.2.5 | 3.1.8 |
| For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords cannot be the same as the four previously used passwords. | 8.2.5a | 3.1.8 |
Stay updated, follow us..
