It is possible that web applications previously considered out-of-scope for PCI DSS could now be in-scope under PCI DSS v3. The impact of this could be significant depending on your existing card data environment (CDE).
It has long been accepted practice that any component that stores, processes or transmits cardholder data is in scope for PCI compliance. Therefore, web applications that only redirect to 3rd party payment gateways are not usually considered in scope, as they do not store, process or transmit cardholder data, nor are they directly connected to such a system.
From a security perspective, this has been a bit of a blind-spot within the PCI DSS. What if the source payment application is compromised in some way? Could this affect the redirection, perhaps tricking the user in to visiting a fraudulent payment page?
This presented a challenge to both QSA and the entity being assessed. A summary of our usual advice is encapsulated as follows:
Should the application doing the redirection be in scope? Yes.Must the application doing the redirection be in scope? No.
And so this uneasy balance of security and compliance went on. Until that is, a closer inspection of wording in the new PCI DSS v3. On page 10, “Scope of PCI DSS Requirements”, there are examples of the kinds of system components that could be considered in scope for assessment (our emphasis):
“Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or
may impact the security of (for example, name resolution or web redirection servers) the CDE. “
There are also further references to “redirection servers” in requirement 10.6, which covers the review of system logs.
It is certainly the case that the new standard tightens it’s grip on requirements where previously, a generous interpretation might suffice. However, this new wording effectively demands that web redirection servers are at least considered as being part of the CDE. The recent PCI SSC European Conference included a discussion of this, and even more recently, the issue was discussed at the QSA session at Visa Europe, London.
On both occasions, it was clear that this historical security blind-spot has not gone unnoticed.
Should the application doing the redirection be in scope? Yes.
Must the application doing the redirection be in scope? Possibly.
In one sense, our advice remains unchanged. That is, all redirection servers should be in scope for security purposes, even if not for compliance purposes. As to whether or not a server must be in scope is now a decision that the QSA will make on an individual basis. The QSA will consider how the redirection is implemented, and a corresponding determination made as to how the server may “impact the security of” the CDE.