PKF AvantEdge

Month: September 2017

PCI-DSS: SAQ A and SAQ A-EP differences in a nutshell

September 14, 2017 / / 0 Comments

OK, we are tackling this wonderful subject for the second time. We have last year touched on this through this post. Unfortunately there are still so many questions on this, that we feel that we need to re-tackle this matter again.

One response a company received regarding this issue from their payment processor was as follows (when merchant requested if they can do SAQ A-EP)

“No. SAQ A-EP you are still not allowed to transmit card data. Please have a look at below snippet taken from the SAQ A-EP AOC:

* All processing of cardholder data, with the exception of the payment page,is entirely outsourced to a PCI DSS validated third-party payment processor.

* Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor.

If you want customers to enter their card data on your website you require the
PCI SAQ D.”

And so, our lengthy reply was as follows:

Your payment processor could be correct (or incorrect) depending on how your page is set up. They are sort of correct in saying you are not allowed to ‘transmit card data’. Because in the SAQ A-EP example, you serve the payment page, and then the card data is transmitted from the user desktop directly to the Payment processor. It is the way the SAQ A-EP is worded that makes it so confusing. You can clearly see that these two statements may sound like they actually conflict each other:

* All processing of cardholder data, with the exception of the payment page,is entirely outsourced to a PCI DSS validated third-party payment processor.

* Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor.

If you read the above, it actually says that, all processing must be outsourced except the payment page (meaning the merchant can host the payment page). The below statement seems to shoot itself in the foot by putting in “The website does not receive cardholder data but controls how cardholder data is ‘redirected’ to a payment processor.” Unfortunately this is not the only place where PCI SSC mucks up its documentation. I can name like a dozen more times they read like its written in Hebrew and translated to English after that.

The only way to really explain is to refer to two documents I will refer to here – first, the “Understanding SAQ document” and the other is from VISA itself, the “Processing Ecommerce Payments Guide” which is what SAQ A vs SAQ A-EP is based on.

Read Page 4 of Understanding SAQ document and tell me how you interpret the table.

Its basically saying the payment page can come from EITHER the merchant website OR a PCI DSS website. As if that’s not enough to clarify, the next page, PCI even gives an example, whereby the “MERCHANT SITE CREATES THE PAYMENT FORM”. So this is clear. The payment form CAN BE IN YOUR WEBSITE.

Apparently they differentiate “receive cardholder data” and creating a payment form doing a direct post to the payment processor. Because in the form, you can send it directly to the processor to process the form posts and input, or you can process it on your own (I used for instance <form action=”PHP_SELF”> which was many years back to reprocess the form input in the same page). The latter example is what they mean by “receive cardholder data”. Not by creating the form itself, but by actually processing what the form is sending when user clicks submit.

You can process it, and then send it to the processor; or you can send it to the processor direct and have them process it.

The first one is SAQ D, the second one is SAQ A-EP. Both occasions the form is still residing on your merchant page. It is what happens after the ‘submit’ is clicked that is important.

If you want to read further, Visa has a better document, the “Processing Ecommerce Payments Guide”. In page 5, the bottom table clarifies a lot.

Basically if you are a merchant 3 and 4 doing either a direct post or javascript, with payment page sitting on your website, then you are eligible for SAQ A-EP.

Lets look at direct post in page 10 and tell me what you are interpreting.

  1. The merchant website CREATES a payment form and SENDS it to the customer computer
  2. The customer computer displays the payment form
  3. The customer enters their card data into the payment form and presses the OK button
  4. The customer computer SENDS the card data to the PSP

The red parts are all done IN YOUR ENVIRONMENT or your customer. Only in step 4 is the card data sent directly to the PSP. So yes, technically, your website is only “serving” the payment page. Once the page is ‘served’, it goes via direct post to the PSP when the submit button is clicked.

SO, in conclusion:  The key thing here is that if your website is directly processing the entries of the forms, then it falls under XML or ‘anything else’ and that’s SAQ D and your processor is correct. This is page 14 of the ecommerce payments guide from VISA. We sometimes see this in merchants who create the form, then for some reason or another prefer to process the information entered into the form and then only sends the information on its way to the processor. They don’t store it, but they process it first before shooting to the processor.

Once more, you can see this by your form. If you have a <form action=”to your own page” or current_page or whatever> then basically you are processing the form before sending to your processor. If your action is to direct to the processor site, then SAQ A-EP can be used.

Hopefully this matter is put to rest!

IATA PCI-DSS: Is GDS Client software a browser? Part 2

September 3, 2017 / / 0 Comments

Right, now that we are past the theory in Part 1 of this article, let’s jump straight into the dissection of the traffic flow.

First of all, we will not be looking at the entire traffic stream of the GDS application. We are not interested in its security for now, but rather whether it is establishing a typical web browser traffic. We need to assume that there is going to be some working knowledge on how networking works, else we will end up giving an entire lesson on it and not get to the point of this article. So, we are not going to explain TCP, HTTP(S) protocols, TLS, handshakes etc. Let’s just assume that we are beyond that and we just need to see if the GDS traffic is similar to the traffic we see on browsers.

In order to do that, we need to look at the basic communication over the internet – handshakes. Like its namesake, a handshake is between two systems – the client and the server and it’s a way of establishing communication. It’s a universally acceptable sign of friendship, although in some countries, it would be a hug, or kiss on the cheeks, or fistbumps. It’s the same thing. A TCP handshake is when your browser fistbumps the server.

However, in this case, because this is considered a “secure” channel we will be using what we know as a TLS (Transport Layer Security) Handshake.

This typically goes like:

a) Client Hello

b) Server Hello

c) Server Key Exchange

d) Client Key Exchange

e) Handshake

f) Let’s chat!

Now, again, this article is not to break down each item and explain every single packet details, but to make a comparison between GDS traffic vs an encrypted browser traffic, to say, Yahoo.com. So what we have done is to use a normal Chrome browser and go to mail.yahoo.com which throws us into the “HTTPS” page, which is the encrypted secure page and from there, we want to establish a connection by logging into Yahoo Mail and looking at the traffic. We are using Wireshark and here is the screenshot:

So as you can see, the beginning has a “Client Hello” packet from our system to Yahoo. This means we are saying, “Hey, here’s what I want from you and here are some information: my TLS version, my cipher suites, my compression method, the server name (so we know who we are talking to) etc. It’s like I give you a name card with all my information in it.

Next, we see a Server Hello. This is great so we know we are not talking to a brick wall. While the Client Hello has information in it, the Server Hello is not just courtesy, it also has piles of instruction on how to communicate. It’s like someone responding to us and saying, “OK, we will be talking in English, we will be using a phoneline at this number, at this time etc etc”. For internet connectivity, TLS versions, cipher suites are important to sync between Client and Server. We won’t go into details here as it is not the objective of this article.

If all goes well, the next step is the Certificate (remember, we are using a secure version of communication here). This certificate does a few things: It gives non-repudiation, meaning, the client knows that it is the server that is sending the information (instead of say, another server pretending to be the actual server). The certificate also provides the important “Public Key” of the server so encryption can occur and the server can decrypt using its own private key.

After this, there might be a Server Key Exchange, which is part of the negotiation flow. At the end of this packet, there is a “Server Hello Done” which is…what it says it is. The Hello is done. Likewise, a Client Key Exchange packet is followed if there is a Server Key Exchange, which in this case, there was. The client is basically encrypting the session with the public key of the server. After these, the TLS handshake is basically done and the transmission is considered secured, and you will see New Session Ticket.

At the end, you will see that “Application Data” packet is encrypted through TLS v1.2.

So this basically constitute a typical browser packet capture for secure communications.

Let’s compare what we get from Travelport:

So here you see the start of the conversation typically begins the same, except there is no Server Key Exchange, and basically the Travelport server sends the “Server Hello Done” message in the Certificate packet itself. This is no big deal, as this is an optional message and the server certificate has the required information.

The client key exchange here is sent to travelport based on the public key algorithm…for the sake of this discussion, this is perfectly normal to either have or not have this, as is the Change Cipher Spec. Finally a “Session Ticket” is also optional (it is missing here) , it’s based on RFC 5077, which basically is session caching on the client side which removes the tracking of each client session on the server side. It’s kind of like those special pass stamps you receive on your hand when you enter into a concert, when you need to take a leak and go outside, the bouncer recognises you on re-entry by the stamp on your hand and you don’t need to do a re-registration again. I really can’t think of another analogy here, so do forgive me if this flies over your head.

So from here, you can see Travelport Galileo Client is actually establishing the same sort of traffic that our Chrome established with Yahoo Mail on the browser. The only thing here we are not comfortable with is the fact that the protocol negotiated is TLS v1, which is not secure and broken. PCI-DSS would have some choice words to say to Travelport on this, as there is a requirement to migrate TLS v1 to v1.1 or v1.2 by June next year 2018.

So let’s look at Sabre:

Again, more or less the same as Travelport except here we have a “Encrypted Handshake Message” which usually occurs after “Change Cipher Spec” since now the messages are no longer unencrypted like the Client Hello, Server Hello etc. Again, it’s part of the normal handshake flow.

With the breakdown as such, we can see that the Travelport client and Sabre client are establishing the same sort of network flow as a browser authenticating to a website, and not doing any local authentication or getting local application data within the client application itself. This generally means, these are specialised “browsers” that are made for only one purpose: connecting to the GDS server. No Facebook access permitted here.

Again, we went through this because we needed some assurance that these GDS clients are functioning similar to browsers, as opposed to standalone payment systems, and from these packet capture, we can surmise (unless stated otherwise by the GDS, IATA or acquiring banks) that these clients are indeed “Internet Based Virtual Terminals”. This gives our travel agencies a measurable confidence to approach this channel with SAQ C-VT (as long as all the other eligibility requirements are met).

Thanks for reading this post, and as always, let us know if you have any queries regarding your PCI-DSS program, at pcidss@pkfmalaysia.com.

IATA PCI-DSS: Is GDS Client software a browser? Part 1

September 1, 2017 / / 0 Comments

We are writing a fair bit on PCI-DSS for travel agencies simply because there is a deadline looming for them in March 2018 to become PCI compliant. While one might surmise there is still plenty of time, on the contrary, even merchant PCI programs will take a few months, and since the end of the year is pretty busy time for traveling, it’s best to get everything in order before the January – March months roll in next year.

So far, we know that the travel agencies are uniquely dealing with their PCI program whereby they have PCI obligations to their acquirer where most of them have card terminals merchant accounts with, and also IATA where they accept card through the “BSP channel”. They are both separate channels, because the BSP channel is actually acceptance of card IN BEHALF of airlines, not part of the agency’s own merchant flow.

So because of this, agencies have options to either fill in a full SAQ D-Mer and submit to acquiring banks and IATA, or to submit an SAQ B (or B-IP) to bank and SAQ C-VT (or C) to IATA. We are now looking into more details to the latter discussion – whether C or C-VT self assessment questionnaire should be filled.

Now before we start, we believe the answer to this is obvious. Ask IATA. We have. But we haven’t got any reasonable response. Next, they can ask the acquirer bank, which is what PCI-SSC suggests. Unfortunately for this channel, the merchant acquirer bank has no visibility over, so they don’t respond. Next, you could probably ask the GDS vendors. Which we also have. Only Amadeus have responded, when we queried whether we were correct in filing out SAQ C-VT: “Basically, if the payment is done via Amadeus and entered manually from a personal computer directly into the GDS – you have (the) right form for Amadeus agents and tick it off with confidence.”

Now it doesn’t really go out of the way to say it, because for this channel, technically, as long as no card data is stored electronically, we need to look at the eligibility of SAQ C vs SAQ C-VT. First of all, SAQ C has 162 questions. SAQ C-VT has 81 questions. More notably, SAQ C-VT does not have obligations for ASV scans whereas SAQ C has. Also, as an introduction for SAQ C, this is mainly designed for restaurants, fast food, franchisees with integrated Point of Sales. You know, the one we see at Oldtown Kopitiam whereby the point of sales system is like a desktop computer that has a LAN connectivity. The SAQ C-VT is designed for very small businesses who needs to enter manually the credit card number to a Virtual Terminal that connects to the acquirer through a ‘web-browser based connectivity’. Now these terms are very important to note, as we go into more details.

The question we have on the table is: Does your GDS channel qualify for SAQ C-VT?

First of all, if you store card data electronically, you can stop reading. You need to do SAQ D-Mer. Go. You have 332 questions to go through and we suggest you start! If not, then the idea here is whether SAQ C or SAQ C-VT is correct for your GDS channel. Now, these are obviously our own opinions, and some other consultants/QSAs might have a different idea or take on it. We do not represent the industry or IATA or PCI SSC in defining this…as and until someone from these parties decides to make a definitive statement of which SAQ needs to be done, this is our suggestion on why SAQ C-VT could be the correct SAQ for the GDS channel.

Now for SAQ C-VT there are a bunch of criteria. You can download the SAQ itself directly at

https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2-SAQ-C_VT.pdf

To save time, we are going to focus on the first three main eligibility points that define this SAQ conditions:

a) Your company’s only payment processing is via a virtual payment terminal accessed by an Internet connected web browser;

b) Your company’s virtual payment terminal solution is provided and hosted by a PCI DSS validated third-party service provider;

c) Your company accesses the PCI DSS-compliant virtual payment terminal solution via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment (this can be achieved via a firewall or network segmentation to isolate the computer from other systems);

Now for A), the key here is “Internet Connected Web Browser”. The other part about ‘Your company’s ONLY payment processing is via a virtual payment terminal’ might mean that if you have any other channels such as internet of EDC (card terminals), you disqualify for this SAQ…but actually no, PCI-SSC states in their Article 1082 that as long as the channels are isolated from each other, you can go ahead and complete different sets of SAQ for different channels.

Now to understand the GDS connectivity, a majority of agencies are using either Sabre, Travelport or Amadeus. Each one of these are supposedly PCI compliant (so item Bcan be checked), and each of these provide a client solution that installs in your desktop and connects back to their main server for information and input. Sabre has their Sabre Red Workspace, Amadeus have their Selling Platform and Travelport have their Galileo Desktop. Some GDS now also offers direct web browser connectivity so that there is no need to install additional client, but for this article, we will be looking at the client application residing in the agent’s desktop. This is key, because if this is considered a stand alone payment application, then SAQ C-VT cannot be fulfilled.

It is this installation of additional client that some consultants have ventured to say that this is not a ‘web browser’, with web browser being what we know as Internet Explorer, Chrome, Safari, Firefox etc to name the popular ones. Without going into the history of web browser itself, the basic definition for the web browser is “a software that retrieves, present and traverse information resources on the internet”. These can also be used to access private web servers or private files in private servers. It is important to note that there must be a call to a web server, usually through encrypted transmissions and there is a dependency on information being posted/sent to this server and receiving a response. Basically, without internet connectivity (except if you have offline data), your web browser is basically non-functional.

So where does this leave us? Unfortunately PCI SSC is cryptic about this ‘Internet Connected Web Browser’ bit in SAQ C-VT. However, it does offer a bit more information about what constitutes a ‘Virtual Payment Terminal’ which is basically:

“Web-browser-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions. Unlike physical terminals, virtual payment terminals do not read data directly from a payment card. The merchant manually enters payment card data via the securely connected web browser. Because payment card transactions are entered manually, virtual payment terminals are typically used instead of physical terminals in merchant environments with low transaction volumes.”

Now we are getting somewhere. So instead of saying Internet connected web browser, here it states a ‘web browser based access’ which might sound like the same thing, but it isn’t. It’s basically stating as long as the software accesses similarly like how a web browser access a resource, then it can be considered as SAQ C-VT qualified. Again in PCI SSC article 1063 in their FAQ:

” SAQ C-VT is for merchants who manually enter a single transaction at a time into an Internet-based virtual terminal solution provided by a PCI DSS validated service provider. “

In this case, it does away with the term ‘web browser’ completely and just states Internet based Virtual terminal.

So let’s establish a few assumptions here to approach this:

a) Software must be dependent on the internet. If there is no connectivity, there is no usage.

b) Like a browser, the software must send and receive information to and from a server

c) Like a web browser, the line should be encrypted if private information is being sent (this is technically more for security than functionality)

If the software can meet these requirements, then it can be considered an internet based virtual terminal. In order for us to really dig into this, we need to go down into the details: doing a packet capture.

We will look into this in more detail in Part 2 immediately after this, which is a separate article, since this one is already way past its word limit already!

© 2024 PKF AvantEdge

— Up ↑