The Payment Card Industry Data Security Standard (PCI DSS) - V4 Compliance Report
This report displays PCI issues found on your site. Many web application vulnerabilities might lead to security breaches of personal information, directly or indirectly, and might be considered as violations of the regulation.
Why it matters
The PCI data security standard offers a single approach to safeguarding sensitive data for all card brands. This standard is a result of collaboration between Visa and MasterCard and is designed to create common industry security requirements. Other card companies operating in the U.S. (such as American Express®, Discover, JCB and Diners) have also endorsed the PCI Data Security Standard within their respective programs. The PCI is intended to protect cardholder data, wherever it resides, and to ensure that members, merchants and service providers maintain high information security standards.PCI DSS Vulnerabilities
| ID | Name |
|---|---|
| Requirement 2 | Apply secure configurations to all system components. |
| Requirement 2.2.2 | If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. If the vendor default account(s) will not be used, the account is removed or disabled. |
| Requirement 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled. |
| Requirement 2.2.6 | System security parameters are configured to prevent misuse. |
| Requirement 4 | Protect cardholder data with strong cryptography during transmission over open, public networks. |
| Requirement 5 | Protect all systems and networks from malicious software. |
| Requirement 6 | Develop and maintain secure systems and applications. |
| Requirement 6.2.1 | Bespoke and custom software are developed securely. |
| Requirement 6.2.4.1 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws. |
| Requirement 6.2.4.2 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data. |
| Requirement 6.2.4.3 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation. |
| Requirement 6.2.4.4 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF). |
| Requirement 6.2.4.5 | Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms. |
| Requirement 6.3 | Security vulnerabilities are identified and addressed. |
| Requirement 6.3.3 | All system components are protected from known vulnerabilities by installing applicable security patches/updates. |
| Requirement 6.4 | Public-facing web applications are protected against attacks. |
| Requirement 6.5.6 | Test data and test accounts are removed from system components before the system goes into production. |
| Requirement 7 | Restrict access to system components and cardholder data by business need to know. |
| Requirement 7.1 | Limit access to system components and cardholder data to only those individuals whose job requires such access. |
| Requirement 7.2.2 | Access is assigned to users, including privileged users, based on: Job classification and function and least privileges necessary to perform job responsibilities. |
| Requirement 7.2.6 | All user access to query repositories of stored cardholder data is restricted as follows: Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges. Only the responsible administrator(s) can directly access or query repositories of stored CHD. |
| Requirement 8.2.8 | If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session. |
| Requirement 8.3.1 | All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: Something you know, such as a password or passphrase. Something you have, such as a token device or smart card. Something you are, such as a biometric element. |
| Requirement 8.3.2 | Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components. |
| Requirement 8.6.2 | Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. |
| Requirement 11.4 | External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected. |