Information Supplement • Penetration Testing Guidance • September 2017
The intent of this document is to provide supplemental information. Information provided here does not
replace or supersede requirements in any PCI SSC Standard.
9
2.2.4 Critical Systems
The term “critical systems” is used in PCI DSS to reference systems that are involved in the processing or
protection of cardholder data. PCI DSS provides examples of critical systems that may be impacted by
identified vulnerabilities including “security systems, public-facing devices and systems, databases, and
other systems that store, process, or transmit cardholder data” (Requirement 6.1). However, for the
purposes of a penetration test, there may be additional systems outside the CDE boundaries that coul
d
affect the security of the CDE. These systems should also be considered to be critical systems. Common
examples of critical systems relevant to a penetration test might include: security systems (for example,
firewalls, intrusion-detection
systems/intrusion-prevention
systems (IDS/IPS), authentication servers, e-
commerce redirection servers, etc.), or any assets utilized by privileged users to support and manage the
CDE. Please note that critical systems are defined by
the entity, as each environment is different.
2.3 Application-Layer and Network-Layer Testing
Any software written by or specifically for the organization that is part of the penetration test scope should be
subject to both an application and network-layer penetration test. This assessment helps identify security
defects that result from either insecure application design or configuration, or from employing insecure coding
practices or security defects that may result from insecure implementation, configuration, usage, or
maintenance of software.
The remediation of vulnerabilities identified during an application-layer assessment may involve redesigning
or rewriting insecure code. The remediation of vulnerabilities identified during a network-layer assessment
typically involves either reconfiguring or updating software. In some instances, remediation may include
deploying a secure alternative to insecure software.
2.3.1 Authentication
If the application requires user authentication to the custom software, testing should be performed against
all roles or types of access assumed by these parties. Also, testing should be performed against any role
or access type that does not have explicit authorization to cardholder data to verify accounts without
access cannot compromise such data.
For customers running applications on multitenant servers that provide customers access to their
cardholder data, authenticated testing should be performed to ensure customer access is properly
restricted to only their own cardholder data. The customer should provide the penetration tester with
credentials that have equivalent permission(s) as a customer user, to allow the penetration tester to
determine whether those credentials allow access to data beyond the entity’s data.
2.3.2 PA-DSS Compliant Applications
If a payment application has been PA-DSS validated, the application’s functionality does not need to be
tested as part of the entity’s PCI DSS compliance validation. However, the implementation of the
application does need to be tested. This includes both the operating system and any exposed services,
but not the payment application’s functionality (e.g., authentication, key management, transaction
processing, etc.) since this was validated as part of the PA-DSS application validation.