3

Suppose I have an ecommerce web site, hosted in Azure (or AWS). I will use a third party payment gateway that is fully certified as PCI level 1. All communication is done with TLS 1.1 or better.

Scenario A: During checkout, a page is presented that asks the user for his details, including credit card. This browser form is served from my server in Azure. When the user hits PAY, using JavaScript we send the card details to the third party gateway to process the payment and wait for the response. At no time are the credit card details sent to my server in Azure.

Scenario B: Instead of serving a credit card form from my site, instead we use the third party gateway's hosted payment page. That means we do a redirect to the gateway's site, where the user enters the card details, and then the browser redirects back to my payment complete page.

Scenario C: Sort of a hybrid, we display the hosted payment page from the gateway in an iframe inside a page served from my server in Azure.

Questions:

  1. In these three scenarios, is there a difference in PCI scope for the server running in Azure? What is the scope? Does our Azure infrastructure need to undergo an annual audit?

  2. Does it make a difference if I am a merchant myself (so the third party gateway is using my merchant account on my behalf) vs a gateway that processes transactions with their own merchant account, and then reimburses me later.

I'm led to believe there is a difference in PCI scope between these scenarios, but I can't really see why. If the Azure server is compromised, an attacker could serve malicious pages and capture the user's card regardless of which approach is used.

I see ecommerce sites using scenario A all the time, but I'm quite sure very few of them are running in PCI compliant environments.

richb
  • 133
  • 4

1 Answers1

4

Caveat IANAQSA

In these three scenarios, is there a difference in PCI scope for the server running in Azure? What is the scope? Does our Azure infrastructure need to undergo an annual audit?

Scope here should be measured as a per-merchant thing, not as a per-server. Yes, your Azure servers would be covered by your scope (the level of which I'll discuss below). AWS is the gold standard for cloud providers helping you understand which scope issues are yours versus theirs. Azure appears to be less helpful in that vein; they point you to PCI, but at least they have a Compliance Matrix.

(absent other details), Scenario A would likely be considered SAQ A-EP scope and scenarios B and C would be SAQ A. Here's a good description from PCIComplianceGuide.org:

the Council says that a merchant can still use SAQ A if:

  • Merchant website provides an inline frame (iframe) to a PCI DSS compliant third-party processor facilitating the payment process.
  • Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process. (Source: Understanding SAQs for PCI DSS Version 3, p. 5)

...

Does it make a difference if I am a merchant myself (so the third party gateway is using my merchant account on my behalf) vs a gateway that processes transactions with their own merchant account, and then reimburses me later.

I don't believe so. Customers go to your site; customers whip out their card and type numbers in; customers expect goods or services in return. You're a merchant, whether you're managing your account with the payment processor or going through a payment facilitator.

I'm led to believe there is a difference in PCI scope between these scenarios, but I can't really see why. If the Azure server is compromised, an attacker could serve malicious pages and capture the user's card regardless of which approach is used.

There is a difference between the SAQ A and A-EP scopes; the former is 14 questions; the latter is closer to 100 and requires scans.

In actual security terms there is negligible difference. Speaking for myself, I think the reasoning that suggests iframes are more secure where javascript is less secure are specious and not technology-driven. Both are equally vulnerable to a malicious attacker who compromises the web server and replaces {iframe,javascript} with their own.

I see ecommerce sites using scenario A all the time, but I'm quite sure very few of them are running in PCI compliant environments.

I'm sure quite a few of them have properly filled out SAQs.

Some subset of those are actually PCI compliant.

Some subset of those are actually secure.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198