About the Maintain a Vulnerability Management Program category
|
|
0
|
29
|
February 9, 2023
|
6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties
|
|
0
|
33
|
February 14, 2023
|
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
|
|
0
|
31
|
February 14, 2023
|
6.5.10 Broken authentication and session management
|
|
0
|
52
|
February 14, 2023
|
6.5.9 Cross-site request forgery (CSRF)
|
|
0
|
33
|
February 14, 2023
|
6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions)
|
|
0
|
39
|
February 14, 2023
|
6.5.7 Cross-site scripting (XSS)
|
|
0
|
36
|
February 14, 2023
|
6.5.7 through 6.5.10, below, apply to web applications and application interfaces (internal or external):
|
|
0
|
39
|
February 14, 2023
|
6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1)
|
|
0
|
39
|
February 14, 2023
|
6.5.5 Improper error handling
|
|
0
|
39
|
February 14, 2023
|
6.5.4 Insecure communications
|
|
0
|
30
|
February 14, 2023
|
6.5.3 Insecure cryptographic storage
|
|
0
|
25
|
February 14, 2023
|
6.5.2 Buffer overflows
|
|
0
|
34
|
February 14, 2023
|
6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws
|
|
0
|
35
|
February 14, 2023
|
6.5 Address common coding vulnerabilities in software-development processes as follows:
|
|
0
|
40
|
February 14, 2023
|
6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable
|
|
0
|
41
|
February 14, 2023
|
6.4.5.4 Back-out procedures
|
|
0
|
33
|
February 14, 2023
|
6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system
|
|
0
|
36
|
February 14, 2023
|
6.4.5.2 Documented change approval by authorized parties
|
|
0
|
31
|
February 14, 2023
|
6.4.5.1 Documentation of impact
|
|
0
|
33
|
February 14, 2023
|
6.4.5 Change control procedures must include the following:
|
|
0
|
25
|
February 14, 2023
|
6.4.4 Removal of test data and accounts from system components before the system becomes active / goes into production
|
|
0
|
44
|
February 14, 2023
|
6.4.3 Production data (live PANs) are not used for testing or development
|
|
0
|
28
|
February 14, 2023
|
6.4.2 Separation of duties between development/test and production environments
|
|
0
|
63
|
February 14, 2023
|
6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls
|
|
0
|
40
|
February 14, 2023
|
6.4 Follow change control processes and procedures for all changes to system components. The processes must include the following:
|
|
0
|
32
|
February 14, 2023
|
6.3.2 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:
|
|
0
|
67
|
February 14, 2023
|
6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers
|
|
0
|
29
|
February 14, 2023
|
6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:
|
|
0
|
32
|
February 14, 2023
|
6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor- supplied security patches. Install critical security patches within one month of release
|
|
0
|
50
|
February 14, 2023
|