When considering application penetration testing for PCI, any software written by your organisation or written specifically for it, should be included in your PCI penetration test scope and should be subject to both network-layer and application layer penetration testing. This form of assessment identifies security defects that result from insecure application design and coding practices or security defects that may result from insecure implementation, configuration or usage of the software.
Remediating vulnerabilities discovered during an application-layer assessment may involve redesigning or rewriting insecure code. Whereas remediating vulnerabilities discovered during a network-layer assessment typically involves either reconfiguring or patching network equipment (e.g. firewall’s, routers, IDS/IPS, Server OS), web server OS (e.g. Linux, Windows Server) or web services software (e.g. Apache, IIS)
Authenticated User Testing
If your application requires user authentication, testing should be performed against all user roles or types of access. Testing should also be carried out against any role or access type that should not have access to cardholder data. This is to verify accounts without explicit authority cannot compromise such data.
If your application is running on a multitenant server that provides other users of that server to access their cardholder data, authenticated testing should be carried out to ensure user access is properly restricted to only their own data.
PA-DSS Compliant Applications
If your payment application has previously been PA-DSS validated, the application’s functionality does not need to be tested as part of the PCI DSS compliance validation (e.g., authentication, key management, transaction processing, etc.). However, the implementation of the application should still be tested, including the operating system and any exposed services.
Web Applications
Many environments include commercial, off-the-shelf web applications, such as web-mail interfaces, document-sharing tools, file-transfer services, network-device administrative interfaces, etc. In this case, the web application does not typically need an application-layer penetration test as the merchant is not responsible for the source code of this type of software. Instead, the tester should perform a network-layer test and ensure that the software was implemented, configured, and is currently being maintained in a secure manner, such as disabling or uninstalling unused services, blocking unused ports, applying current updates, etc.
Separate Testing Environment
Due to the nature and the techniques of penetration testing, such testing in a production environment during normal business hours could have an impact on business operations, and attempts to avoid disruption may increase the time, resources necessary to complete the testing. This is particularly important for systems with high availability requirements. To avoid potential disruptions and to speed up testing, a separate environment that is identical to the production environment can be used for testing instead of the production environment. The tester would need to ensure the same application and network-layer controls that exist in production are present in the testing environment. This may be accomplished through methods to map out the production environment to verify it matches the testing environment and should be made clear in the rules of engagement.