PA-DSS

Summary

The PCI Payment Application Data Security Standard (PA-DSS) Requirements and Security Assessment Procedures define security requirements and assessment procedures for software vendors of payment applications. The version used in this section is PA-DSS version 3.0, November 2013.

Definitions

Definition	Requirements
1_1. Do not store sensitive authentication data after authorization	360. Remove unnecessary sensitive information
1_1_1. Do not store full contents of any track from the magnetic stripe	160. Encode system outputs 335. Define out of band token lifespan 360. Remove unnecessary sensitive information
1_1_2. Do not store the card verification value or code used to verify transactions	160. Encode system outputs 335. Define out of band token lifespan 360. Remove unnecessary sensitive information
1_1_3. Do not store personal identification number (PIN) or the encrypted PIN block	205. Configure PIN 360. Remove unnecessary sensitive information
1_1_4. Securely delete any track data, card verification values or codes, and PINs or PIN block data stored by application in accordance with industry-accepted standards	183. Delete sensitive data securely 335. Define out of band token lifespan 360. Remove unnecessary sensitive information
1_1_5. Do not store sensitive authentication data on vendor systems	083. Avoid logging sensitive data
2_1. Provide guidance to customers regarding secure deletion of cardholder data	183. Delete sensitive data securely 360. Remove unnecessary sensitive information
2_2. Mask PAN when displayed	300. Mask sensitive data
2_3. Render PAN unreadable anywhere it is stored	127. Store hashed passwords 185. Encrypt sensitive information 305. Prioritize token usage
2_5. Implement key management processes and procedures for cryptographic keys used for encryption of cardholder data	145. Protect system cryptographic keys 252. Configure key encryption
2_5_1. Generation of strong cryptographic keys	145. Protect system cryptographic keys 224. Use secure cryptographic mechanisms
2_5_2. Secure cryptographic key distribution	181. Transmit data using secure protocols 300. Mask sensitive data
2_5_3. Secure cryptographic key storage	145. Protect system cryptographic keys 146. Remove cryptographic keys from RAM
2_5_4. Cryptographic key changes for keys	338. Implement perfect forward secrecy 361. Replace cryptographic keys
2_5_5. Retirement or replacement of keys	361. Replace cryptographic keys
2_5_7. Prevention of unauthorized substitution of cryptographic keys	145. Protect system cryptographic keys 176. Restrict system objects
3_1. Support and enforce the use of unique user IDs and secure authentication for all administrative access	033. Restrict administrative access 229. Request access credentials
3_1_2. Enforce the changing of all default application passwords for all accounts	142. Change system default credentials
3_1_4. Application employs methods to authenticate all users	228. Authenticate using standard protocols 229. Request access credentials 231. Implement a biometric verification component 305. Prioritize token usage 357. Use stateless session tokens
3_1_5. Payment application does not require or use any group, shared, or generic accounts and passwords	143. Unique access credentials 362. Assign MFA mechanisms to a single account
3_1_6. Passwords must meet minimum requirements	132. Passphrases with at least 4 words 133. Passwords with at least 20 characters
3_1_7. Payment application requires changes to user passwords at least every 90 days	130. Limit password lifespan
3_1_11. Require the user to re-authenticate to re-activate the session (inactive)	023. Terminate inactive user sessions 141. Force re-authentication
3_3_1. Use strong cryptography to render all payment application passwords unreadable during transmission	181. Transmit data using secure protocols
3_4. Limit access to required functions/resources and enforce least privilege for built-in accounts	035. Manage privilege modifications 186. Use the principle of least privilege
4_1. Log all user access and be able to link all activities to individual users	085. Allow session history queries 377. Store logs based on valid regulation
4_2_2. Actions taken by any individual with root or administrative privileges	046. Manage the integrity of critical files 075. Record exceptional events in logs
4_2_4. Invalid logical access attempts	075. Record exceptional events in logs
4_2_5. Changes to the application's identification and authentication mechanisms with root or administrative privileges	075. Record exceptional events in logs
4_2_6. Initialization, stopping, or pausing of the application audit logs	046. Manage the integrity of critical files 075. Record exceptional events in logs
4_2_7. Creation and deletion of system-level objects	075. Record exceptional events in logs 079. Record exact occurrence time of events
4_3. Payment application's audit log settings and audit log output	079. Record exact occurrence time of events
4_4. Facilitate centralized logging	377. Store logs based on valid regulation
5_1_1. Live PANs are not used for testing or development	180. Use mock data
5_1_2. Test data and accounts are removed before release to customer	154. Eliminate backdoors
5_1_5. Secure practices are implemented to verify integrity of source code during the development process	330. Verify Subresource Integrity
5_2_1. Injection flaws, particularly SQL injection	050. Control calls to interpreted code 160. Encode system outputs 169. Use parameterized queries 173. Discard unsafe inputs 321. Avoid deserializing untrusted data
5_2_2. Buffer Overflow	157. Use the strict mode 173. Discard unsafe inputs 345. Establish protections against overflows
5_2_3. Insecure cryptographic storage	145. Protect system cryptographic keys 185. Encrypt sensitive information 224. Use secure cryptographic mechanisms
5_2_4. Insecure communications	181. Transmit data using secure protocols 336. Disable insecure TLS versions
5_2_5. Improper error handling	077. Avoid disclosing technical information 078. Disable debugging events
5_2_7. Cross-site scripting (XSS)	029. Cookies with security attributes 173. Discard unsafe inputs 340. Use octet stream downloads 344. Avoid dynamic code execution 349. Include HTTP security headers
5_2_8. Improper access controls	033. Restrict administrative access 035. Manage privilege modifications 080. Prevent log modification 096. Set user's required privileges 176. Restrict system objects 186. Use the principle of least privilege 265. Restrict access to critical processes 266. Disable insecure functionalities 320. Avoid client-side control enforcement 341. Use the principle of deny by default
5_2_9. Cross-site request forgery (CSRF)	029. Cookies with security attributes 174. Transactions without a distinguishable pattern 349. Include HTTP security headers
5_2_10. Broken authentication and session management	029. Cookies with security attributes 032. Avoid session ID leakages 369. Set a maximum lifetime in sessions
5_4_6. Process in place to review application updates	302. Declare dependencies explicitly 353. Schedule firmware updates
6_1. The wireless technology must be implemented securely	084. Allow transaction history queries 142. Change system default credentials 181. Transmit data using secure protocols 248. SSID without dictionary words 250. Manage access points 251. Change access point IP 252. Configure key encryption 253. Restrict network access 257. Access based on user credentials 273. Define a fixed security suite 353. Schedule firmware updates
6_2. For wireless technology, implement strong encryption for authentication and transmission	181. Transmit data using secure protocols 249. Locate access points 252. Configure key encryption 253. Restrict network access 255. Allow access only to the necessary ports 257. Access based on user credentials
8_1. Secure network environment	273. Define a fixed security suite 374. Use of isolation methods in running applications
8_2. Use of necessary and secure services, including those provided by third parties	161. Define secure default options 262. Verify third-party components
8_3. Operation of two-factor authentication technologies for secure remote access	319. Make authentication options equally secure 362. Assign MFA mechanisms to a single account
9_1. Any web server and any cardholder data storage component are not required to be on the same server	261. Avoid exposing sensitive information 339. Avoid storing sensitive files in the web root
10_2_2. Unique authentication credential must be used for each customer environment	128. Define unique data source 143. Unique access credentials
10_2_3. Remote access to customer's payment applications must be implemented securely	025. Manage concurrent sessions 083. Avoid logging sensitive data 142. Change system default credentials 176. Restrict system objects
11_1. Use of strong cryptography and security protocols to safeguard sensitive cardholder data during transmission	176. Restrict system objects 178. Use digital signatures 181. Transmit data using secure protocols
11_2. Render the PAN unreadable	185. Encrypt sensitive information
12_1. Encrypt all nonconsole administrative access with strong cryptography	033. Restrict administrative access 185. Encrypt sensitive information 336. Disable insecure TLS versions

Free trial

Search for vulnerabilities in your apps for free with Fluid Attacks' automated security testing! Start your 21-day free trial and discover the benefits of the Continuous Hacking Essential plan. If you prefer the Advanced plan, which includes the expertise of Fluid Attacks' hacking team, fill out this contact form.

PA-DSS | Compliance | Fluid Attacks Help

PA-DSS

Summary

Definitions