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
PADSS-1_1. Do not store sensitive authentication data after authorization	360. Remove unnecessary sensitive information
PADSS-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
PADSS-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
PADSS-1_1_3. Do not store personal identification number (PIN) or the encrypted PIN block	205. Configure PIN 360. Remove unnecessary sensitive information
PADSS-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
PADSS-1_1_5. Do not store sensitive authentication data on vendor systems	083. Avoid logging sensitive data
PADSS-2_1. Provide guidance to customers regarding secure deletion of cardholder data	183. Delete sensitive data securely 360. Remove unnecessary sensitive information
PADSS-2_2. Mask PAN when displayed	300. Mask sensitive data
PADSS-2_3. Render PAN unreadable anywhere it is stored	127. Store hashed passwords 185. Encrypt sensitive information 305. Prioritize token usage
PADSS-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
PADSS-2_5_1. Generation of strong cryptographic keys	145. Protect system cryptographic keys 224. Use secure cryptographic mechanisms
PADSS-2_5_2. Secure cryptographic key distribution	181. Transmit data using secure protocols 300. Mask sensitive data
PADSS-2_5_3. Secure cryptographic key storage	145. Protect system cryptographic keys 146. Remove cryptographic keys from RAM
PADSS-2_5_4. Cryptographic key changes for keys	338. Implement perfect forward secrecy 361. Replace cryptographic keys
PADSS-2_5_5. Retirement or replacement of keys	361. Replace cryptographic keys
PADSS-2_5_7. Prevention of unauthorized substitution of cryptographic keys	145. Protect system cryptographic keys 176. Restrict system objects
PADSS-3_1. Support and enforce the use of unique user IDs and secure authentication for all administrative access	229. Request access credentials 033. Restrict administrative access
PADSS-3_1_2. Enforce the changing of all default application passwords for all accounts	142. Change system default credentials
PADSS-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
PADSS-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
PADSS-3_1_6. Passwords must meet minimum requirements	132. Passphrases with at least 4 words 133. Passwords with at least 20 characters
PADSS-3_1_7. Payment application requires changes to user passwords at least every 90 days	130. Limit password lifespan
PADSS-3_1_11. Require the user to re-authenticate to re-activate the session (inactive)	141. Force re-authentication 023. Terminate inactive user sessions
PADSS-3_3_1. Use strong cryptography to render all payment application passwords unreadable during transmission	181. Transmit data using secure protocols
PADSS-3_4. Limit access to required functions/resources and enforce least privilege for built-in accounts	186. Use the principle of least privilege 035. Manage privilege modifications
PADSS-4_1. Log all user access and be able to link all activities to individual users	377. Store logs based on valid regulation 085. Allow session history queries
PADSS-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
PADSS-4_2_4. Invalid logical access attempts	075. Record exceptional events in logs
PADSS-4_2_5. Changes to the application's identification and authentication mechanisms with root or administrative privileges	075. Record exceptional events in logs
PADSS-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
PADSS-4_2_7. Creation and deletion of system-level objects	075. Record exceptional events in logs 079. Record exact occurrence time of events
PADSS-4_3. Payment application's audit log settings and audit log output	079. Record exact occurrence time of events
PADSS-4_4. Facilitate centralized logging	377. Store logs based on valid regulation
PADSS-5_1_1. Live PANs are not used for testing or development	180. Use mock data
PADSS-5_1_2. Test data and accounts are removed before release to customer	154. Eliminate backdoors
PADSS-5_1_5. Secure practices are implemented to verify integrity of source code during the development process	330. Verify Subresource Integrity
PADSS-5_2_1. Injection flaws, particularly SQL injection	160. Encode system outputs 169. Use parameterized queries 173. Discard unsafe inputs 321. Avoid deserializing untrusted data 050. Control calls to interpreted code
PADSS-5_2_2. Buffer Overflow	157. Use the strict mode 173. Discard unsafe inputs 345. Establish protections against overflows
PADSS-5_2_3. Insecure cryptographic storage	145. Protect system cryptographic keys 185. Encrypt sensitive information 224. Use secure cryptographic mechanisms
PADSS-5_2_4. Insecure communications	181. Transmit data using secure protocols 336. Disable insecure TLS versions
PADSS-5_2_5. Improper error handling	077. Avoid disclosing technical information 078. Disable debugging events
PADSS-5_2_7. Cross-site scripting (XSS)	173. Discard unsafe inputs 340. Use octet stream downloads 344. Avoid dynamic code execution 349. Include HTTP security headers 029. Cookies with security attributes
PADSS-5_2_8. Improper access controls	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 033. Restrict administrative access 035. Manage privilege modifications 080. Prevent log modification 096. Set user's required privileges
PADSS-5_2_9. Cross-site request forgery (CSRF)	174. Transactions without a distinguishable pattern 349. Include HTTP security headers 029. Cookies with security attributes
PADSS-5_2_10. Broken authentication and session management	369. Set a maximum lifetime in sessions 029. Cookies with security attributes 032. Avoid session ID leakages
PADSS-5_4_6. Process in place to review application updates	302. Declare dependencies explicitly 353. Schedule firmware updates
PADSS-6_1. The wireless technology must be implemented securely	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 084. Allow transaction history queries
PADSS-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
PADSS-8_1. Secure network environment	273. Define a fixed security suite 374. Use of isolation methods in running applications
PADSS-8_2. Use of necessary and secure services, including those provided by third parties	161. Define secure default options 262. Verify third-party components
PADSS-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
PADSS-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
PADSS-10_2_2. Unique authentication credential must be used for each customer environment	128. Define unique data source 143. Unique access credentials
PADSS-10_2_3. Remote access to customer's payment applications must be implemented securely	142. Change system default credentials 176. Restrict system objects 025. Manage concurrent sessions 083. Avoid logging sensitive data
PADSS-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
PADSS-11_2. Render the PAN unreadable	185. Encrypt sensitive information
PADSS-12_1. Encrypt all nonconsole administrative access with strong cryptography	185. Encrypt sensitive information 336. Disable insecure TLS versions 033. Restrict administrative access

Last updated

2023/09/18