PA-DSS | Compliance | Fluid Attacks Help

PA-DSS

logo

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 message
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.