PKF AvantEdge

Category: IATA PCI-DSS (Page 1 of 2)

Do or Do Not – ASV for SAQ A

July 24, 2021 / / 0 Comments
pci-compliance

I would have thought this debate died out with the extinction of dinosaurs, but apparently, we are still at this subject in 2021. Still. Going. On.

So in the past weeks, there were some debate between us and some consultants as to whether the SAQ A requires an ASV scan or not. Our position was No. Their position was yes. So let’s look at it.

Now, keep in mind, we aren’t talking about best practice. We are talking about PCI-DSS v3.2.1 and what it says about ASV scans being mandatory for SAQ A. That’s it. That’s the statement. Now, debate.

There is actually no debate. This isn’t some sort of grey area, hard to explain, obscure rule in Sanskrit and written on the Sankara stones. This is just: Look at SAQ A, search for ASV, don’t find it. Thank you.

The ASV requirement is present in item 11.2.2 of PCI-DSS.

SAQ A does not have it.

So why do consultants still insist people do ASV scans for SAQ A?

There could be a lot of reasons, ranging from ‘guideline’, ‘best practice’ and so on. No doubt, having a scan (which isn’t expensive in any case) would be the least effort of security done by the merchant if they are hosting an e-commerce website that is redirecting customers to their payment processor once the “Click here to pay” is clicked. I mean, even if it has nothing to do with PCI, it may seem like common sense to have at least a scan done on your site to ensure it passes the very minimal requirement of security. So do we advocate an ASV scan to be done on any e-commerce site that deals with payment options (not necessarily payment data)? Yes, we do. There are many ways a site may get compromise. A coding error may allow data to be siphoned off, or passwords may be compromised. A re-direct may be vulnerable to man in the middle attacks; or even a total redirect to another page altogether where payment data is inadvertently entered. While the e-commerce site may be outsourcing the payment part to a processor, it still has the job of redirecting traffic to it.

Think of it as an usher (not the singer, but the job); where you enter into a dark auditorium, let’s say Royal Albert Hall to watch Ed Sheeran – and the usher takes you through this row of lights to what is supposedly your seat which you paid RM10,000 for.

When the lights come on, you find yourself in nice cosy room and in front of you someone who seemed to resemble Ed Sheeran but slightly off. His hair isn’t ginger and he isn’t as chubby as you see that guy on TV and he speaks with a slight Indian accent. And isn’t the Royal Albert Hall a HALL? Why are you in this room that resembles a glorified grandmother’s living room? You find out later that the usher had led you through the wrong Hall into a neighboring pub attached to the side of the hall and you are listening to the wonky music of Eddy Shiran.

The point is, the usher is pretty important in leading people to their seats. So as a redirect, even though you aren’t the main draw, you could end up leading your customers to Eddy Shiran instead.

But back to the main debate, whether it is required for SAQ A customers to go through ASV? No, it’s not.

However, there is always a but in everything. There are exceptions.

Some acquirers make it a point to state that they still require an ASV report even if merchants are going through SAQ A. That’s completely fine because the guidelines from Visa/Mastercard are just guidelines. At the end, the acquirer or payment brands may make individual decisions based on merchants, so it’s not written in stone. However, if there are no such requirement, we’re left to interpret the SAQ as it is, and it doesn’t state anything there.

Some may point out within the SAQ A under part 3a, there is a statement

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name)

Triumphantly being pointed out as proof of ASv requirement

Take note however, that above, under Part 3a, the instructions do state:

Signatory(s) confirms:
(Check all that apply)

the realisation that asv is still not needed for Saq A (or B)

Even under the title “PCI DSS Self-Assessment Completion Steps” of the SAQ:

Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation—such as ASV scan reports—to your acquirer, payment brand, or other requester.

It does seem to be grappling at straws if this sentence was used to justify the requirement for PCI-DSS. “Such as” generally denotes an example, which may or may not exist or is required.

In previous requirements of merchants from Visa, there used to be statements describing merchant levels such as 

 * Merchant levels are based on Visa USA definitions
** The PCI DSS requires that all merchants perform external network scanning to achieve compliance. Acquirers may require submission of scan reports and/or questionnaires by level 4 merchants

And perhaps there is where the myth was perpetuated from. In recent times Visa has updated its site (https://www.visa.com.my/support/small-business/security-compliance.html) to reflect a better understanding, stating:

“Conduct a quarterly network scan by an Approved Scan Vendor (“ASV”) (if applicable)”

In conclusion, SAQ A and B do not require ASV scans. If it’s required by the acquirer then so be it. If it’s supposed to be done out of best practice requirements, so be it. But you don’t want to hear an ASV/QSA telling you that you need to do something that is above and beyond your PCI requirement without them pointing to something in the standards that states so.

Finally – for SAQ B, which usually applies to POS terminals dialing up to the bank for authorisation; we’ve even seen some consultants requiring the merchant’s website to undergo ASV, which has nothing to do with their POS Terminals. Why ASV the website? Don’t know. So the merchants go about scanning their website that hasn’t been updated since 2012 and wonder, what sort of nonsensical requirement is this from PCI-DSS that needs them to pay just to scan something that is built by an 18 year old intern who had left the company 10 years ago? You don’t need to. So don’t do it.

Anyway, that’s it for now. Let us know your thoughts or questions and send to us at pcidss@pkfmalaysia.com and we will get back to you ASAP. Now, back to listening to our Spotify for Eddy Shiran!

PCI-DSS Segmentation with Host-Based Firewalls

February 17, 2018 / / 2 Comments

One of the frequent queries we have faced in the past months as we ramp up our consultancy and advisory for travel agencies and other merchants, has been the question of segmentation.

Now, before travel agencies were imposed with the requirement for PCI-DSS by IATA, we had very few opportunities to work with small merchants for PCI-DSS. It’s not because small merchants are exempted from PCI. They are not. Small merchants must be PCI compliant, but in reality, very few banks are chasing smaller merchants for their compliance. Our experience with merchants had been with the fairly large ones – the large petrol companies, the large retailers, the telcos and the largest travel agency being our experiences. From the time we started PCI back in 2010 to around 2014, it has mainly been for financial institutions and banks. But now with IATA flexing their regulatory muscle to make sure agencies are PCI compliant by 1st of March 2018, we have had plenty of opportunities to go into much smaller environments that we are used to. And it has been a really great experience.

So when we discuss about the topic of network segmentation, we need to be clear from the start:- it’s actually NOT a PCI-DSS requirement. PCI doesn’t state that we need to segment our network. We could very well be PCI compliant on a flat network. Page 11, of PCI-DSS v3.2 states so:

“Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment.”

And we have done this before. One of our client has a completely isolated network for PCI-DSS with its own gateway and basically its a flat network with everything as CDE (Card Data Environment). Possible, but in enterprise environment, probably not so realistic if it drags in hundreds of systems. Without going too much into scoping, the main topic of this article is: if we need to segment, how do we do it?

At the onset, the question seems superfluous. How to segment? Why, by network subnets of course, or by VLANs (virtual LANs). These terms (subnet and VLAN) have been used interchangeably by myriad of customers over the years, and in most cases, they actually do multiple VLANs across different subnets, but in theory you can also have VLANs on single subnet as well. So, no – VLANs and subnetting are actually not the same but for the sake of not being pedantic, most of the time, we just allow the client to use whichever term they choose.

In most cases over the years, our clients won’t have a problem with this. Segmenting either via VLAN or network subnet, they can achieve this fairly easily through their switch or their edge router, as they usually have advanced firewalls/routers/L3 switches deployed in their network.

But going into the very small companies with a handful of people, no technology personnel, and running the D-Link DIR-615 low end routers provided by Telekom? How do we do this?

We have heard other consultants declare that these companies need to invest in enterprise grade firewalls/routers to achieve PCI compliance, because some of the entry level router/firewalls are unable to do any segmentation or VLAN. Of course, you could hack the DIR-615 to WRT and that might provide you some limited VLAN capability, but that’s beyond the scope of this article. And in any case, we doubt any of the smaller merchants have the inclination to fiddle around with their routers. So if you are stuck with a firewall/router that cannot do any network segmentation, does that mean that everything needs to be brought into scope? Does that mean you need to spend thousands to get a firewall upgrade?

So let’s have a couple of references here. First of all, the canon document from PCI will help, this is the official PCI-DSS v3.2 documentation, page 11, stating a few salient points:

Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment.

This phrase actually enables many people to pre-suppose that PCI is stating that the only segmentation allowed here is by the methods we discussed above – i.e anything that creates a non-flat network. But this is confusing because when we say ‘flat network’, we are already indicating we are referencing to Layer 3. However it’s entirely possible to have layer 2 VLAN isolating systems within the SAME SUBNET (multiple VLANs – Single Subnet design). Heck, you could even have multiple subnet on a single VLAN if you want … I think I remember this from my Cisco CCNP days. So, actually, in theory , unless PCI refers to something else when it says ‘Flat Network’, their statement isn’t that accurate. You could isolate systems in a flat network.

Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network.

While agreeing on this one as a whole, the other confusion here is the term “Physical OR logical”. As tech nerds, we take these conjunctions very seriously. For instance,  my wife asked me the other day if I wanted a cheeseburger OR a double quarterpounder happy meal. The answer to that would be “TRUE”, meaning, Yes, I can have cheeseburger OR a double quarterpounder since “OR” here is inclusive. As long as any or both of those statements are true, it’s true.  This is usually what we do in Boolean values, for instance

1 > 2 || 3 > 2 = TRUE

1 > 2 && 3>2 = FALSE

So back to the phrase Physical OR logical, this generally means PCI accepts Physical segmentation, even if there is NO LOGICAL SEGMENTATION? What does that mean? Does it mean if I have two systems hooked into the same switch, on the same network, pinging each other, I set up a physical brick wall between these two systems, I have achieved Network Segmentation? Surely not. The physical segmentation example here would be having two separate switches servicing two different networks as opposed to using a single switch and using it’s logical functions to achieve that segmentation. Can both be used or one or the other? Yes, either can be used. So whoever have written this phrase either needs to clarify this statement proper, or simply, he or she is !(Tech Nerd).

At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not.

So finally they decide and say, ok, anything that ISOLATES systems can be considered network segmentation. So at least we have a lead here to go with. Anything that ISOLATES.

The next journey we take is to this document:

https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf

Section 3.1, page 13:

Examples of controls that could be applied to prevent out-of-scope systems from compromising a connected-to or security-impacting system include:

– Host-based firewall and/or intrusion detection and prevention system (IDS/IPS) on in scope systems that block connection attempts from out-of-scope systems.

This is one indication that PCI looks at alternate ways of ‘segmentation’, other than getting an enterprise grade network firewall. Once more, the conjunction used here is “AND/OR”, which we take to mean, either AND (&&) or OR (||) can be used for these two statements (Host-based firewall, IDS/IPS). So what this basically states is that a host-based (not network firewall) firewall is good enough, if configured properly to be considered as a segmentation tool.

Now if you do know a little history behind this documentation, it has a grandfather document called “Open PCI DSS Scoping Toolkit”, a copy can be found here:

https://www.isaca.org/Groups/Professional-English/pci-compliance/GroupDocuments/OpenPCIScopingToolkit.pdf

This was way before the PCI-DSS document came about. We had to use the OPEN PCI scoping toolkit to define what is in scope, not in scope, CDE, non-CDE in scope etc. This is why sometimes we say systems that are non CDE are ‘infected’ , i/e pulled into scope because they are in the same subnet/VLAN. This term isn’t found in the PCI document but is used in the old scoping toolkit document. Of course, this document is deprecated and the SSC doesn’t officially endorse it. However, some concepts had made its way into the SSC scoping document and what we are focusing here is mainly on the usage of host based firewall, and whether it’s logical for it to be used for some sort of segmentation. Other parts of this document has been succeeded by the official PCI scope document, so be aware. Back to this document, a few QSAs had looked at us in amusement when we used these terms and some even commented that these are very strange terms we are using, showing how young these QSAs actually are. I am not sure about the other regions, but I have had discussions with QSAs who are 10-15 years younger than me and never had one day of experience in actual security operations. One QSA even insisted we put our logging system into the DMZ as good security practice, which I then responded with an emoji face slap to our customer. With all due respect to QSAs, I have had many arguments with them over the years – some are very good, very experienced; while some are, as Bart Simpson would put it: “Meh.”

Anyway, we digress.

In the scoping toolkit, Page 13 gives an indication of what we are talking about:

The mechanism providing the isolation or controlled access functionality may be either logical or physical. Examples of mechanisms include network and host-based firewalls, virtual routing and switching appliances, and access control lists

This is still less clear due to our “AND” and “OR” arguments, because aside from the illogical “logical or physical” statement (which PCI clearly inherited), we have the problem stating “network and host-based firewalls, virtual routing and switching appliances, and access control lists”. This, to us, might mean we need ALL of these things for isolation to be TRUE.

Thankfully, this is clarified further down in Page 36:

In order to restrict other workstations on the same network from being “infected,” the dumb terminals must be isolated (e.g., using a host-based or network-based firewalls, etc.).

The example here is “using a host-based or network-based firewalls.”. As you now are very well aware, this means this statement is true if any of these options, or both these options are true.

You see, some writers do not think twice about the usage of “AND” and “OR” operators or ‘conjunctions’ to normal English-speaking people. These are extremely powerful operators and carry entirely different meanings to what normal people may deem as normal sentences having the same meaning. Another key life example here would be if your wife (again a very relevant example) were to ask you after a late night out with the guys whether you’ve been to the bar to watch football or to watch strippers, to which you respond: “YES”.

So be careful because different people parses sentences differently, depending on whether you see life in code or not. It could very well change your life.

We have also discussed this topic of segmentation at length with some senior QSAs (QSAs who have much more experienced compared to the green horns) and they have agreed that host-based firewall, or Host IDS are acceptable forms of isolation, but requires a significant amount of configuration to ensure isolation is done properly. “Done properly” here carries a fairly subjective weight to it. QSAs are a funny lot, because many of the requirements in PCI are general, and then it’s up to the QSAs to decide whether a particular control satisfies their own concerns whatever that might be. To summarise, segmentation can be carried out easier through deployment of a network firewall and getting the segmentation rules sorted out there, but if the merchant is short on funds, and have 1 or 2 systems only to configure, a fix could be a “properly configured” host-based firewall, or a host-based IDS/IPS.

Segmentation testing still needs to occur, though, but that will be for another article for another day.

Now, I will have my coffee OR tea to finish up my day. TRUE.

For more information on PCI-DSS, feel free to drop us an email at pcidss@pkfmalaysia.com.

IATA PCI-DSS: New FAQs!

January 23, 2018 / / 0 Comments

So, it has been a while since we’ve updated on the ongoing PCI-DSS program from IATA. Just a brief recap then: Airlines have demanded that IATA support their own internal compliance project by making the BSP (Billing Settlement Plan) card sales channel PCI DSS compliant. This is why IATA Accredited Travel Agents now need to become PCI DSS compliant by 1st March 2018. Yes, that’s roughly 6 weeks ahead of this writing. And no, it doesn’t seem like there might be any extension towards this compliance from IATA. However, there are some pretty big news headed your way on this compliance, as we are in touch with IATA over the last couple of months and also assisting many travel agencies to get PCI-DSS sorted out in their payment channels.

However, for this article, we will focus on the brand new FAQs that just came out a few days ago (18 Jan 2018)! You can find the updated FAQs here at http://www.iata.org/services/finance/Documents/pci-dss-faqs.pdf, and we are going to look through a few changes.

FAQ #3

What if I do not have an acquirer?

Old FAQ: We suggest that you contact the credit card branch that you are working with.

New FAQ: In that case, you are solely accountable for the PCI DSS compliance of the BSP card transactions you are making on account of the airline whose ticket you are selling. We suggest you contact your GDS provider who can provide some guidance, and then review through which of your systems card details transit or are stored. Starting from this you will know which of your systems
must undergo a PCI DSS evaluation.

Our opinion: The first FAQ was of course, not exactly extremely helpful, since most credit card branch does not give two hoots about travel agencies banging down their doors in search of their response. The new FAQ is basically saying, well – you just need to figure out yourself then, but you can ask the GDS guys if you wish. We have. The GDS guys are very important in this factor, because they first need to be PCI compliant. Sabre, Amadeus and I think Galileo Travelport is. Secondly, they can give some guidance on how agencies can approach PCI based on the client software that is installed on the agency side.

What do we mean by this? Because for agencies not storing credit card, they can possibly be eligible for shorter SAQ (Self Assessment Questionnaires) for PCI. An SAQ D has 340+ questions. An SAQ A has only 20+. If an agency uses the GDS for credit card passthrough transactions (i.e the credit card form of payment), and not store credit card information in the back office or any electronic form (email, skype, excel etc), they might qualify for shorter SAQs. The question is which?

Some advisors claim the SAQ C is correct due to the fact that the GDS is a payment system. The reasoning is that this is no different from integrated POS systems like Micros. In Malaysia, we have hundreds of different vendors in POS solutions for retailers, F&B franchisees etc. But is the GDS really like an integrated POS solution? SAQ C has around 160 questions. The amount of time you will spend on this is probably the same amount of time taken to watch two seasons of the Game of Thrones. Or three, depending on whether you binge watch or not.

Some advisors veer to the other extreme, claiming that the GDS client is simply a browser system that is redirecting the entire card data processing work to the GDS provider, so they are eligible for A. 22 questions. Maybe an episode of Seinfeld. But A is generally for a web browser based site with absolutely zero handling of credit card on their end, not just systematic, but also manual. The only way this works for travel agency is that they outsource an entire call center to handle their MOTO business and do not accept walk-in customers. I don’t think that’s happening. Most feedback I get from livid agencies about PCI-DSS is that they are struggling too much on thin margins. So, no, SAQ A is entirely too liberal.

SAQ C-VT has a seemingly better balance to it, as discussed in our previous articles Part 1 and Part 2.

We even sent out queries to two GDS (their names pending once I get their agreement to publish) and their responses were these

Amadeus: (When Queried if SAQ C-VT is correct to be filled, and if the Amadeus Selling Platform can be eligible for VT): Basically, if the payment is done via Amadeus and entered manually from a personal computer directly into the GDS – you have a right form for Amadeus agents and tick it off with confidence. 

I believe your original question was ‘If Amadeus is considered virtual payment terminal?’

Our answer is Yes.

Sabre: (When asked if their client acts as a VT, defined by PCI as having “Internet-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions.”) Yes, Sabre Red Workspace client requires an internet connection to authenticate and then it requires connections (dedicated or ISP with VPN) to connect to Sabre and no, it does not do batch processing. You may consider SRW is a virtual terminal and guiding your travel agency clients to achieve their goal.

Travelport (Galileo):  (When asked if their client acts as a VT, defined by PCI as having “Internet-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions.”)

Yes. Galileo client does not store credit card information on the client software and client software requires internet connectivity, and cannot do batch transactions.

Based on these ‘guidance’ from GDS which IATA seem to defer to, SAQ C-VT is a likely possibility, as long as all the other eligibility are met. The GDS all claims they are virtual terminals, but that itself (while an important eligibility) isn’t the ONLY eligibility for SAQ C-VT, so you need to ensure the others are met before claiming SAQ C-VT is correct or your business.

Whew. That was a long one. Now back to our FAQs.

FAQ #9 : As a travel professional issuing and selling airline tickets, am I considered a merchant?

This is removed and rightly so. Though the previous response was right: “All the airline transactions processed through a GDS (Global Distribution System) and IATA BSP, the airline itself is considered as the merchant, not the travel agent.”

It only serves to confuse an already confused population further. It’s better they don’t explain this, because some agencies interpret this as IATA saying they are not ‘merchants’ so they need to be ‘service providers’. WHAT! So, yeah, we can explain in another article but this is better left out.

FAQ #22: We already have a PCI DSS Compliant certificate issued by a third party.
Is this enough to cover our BSP or do we need to complete more forms?

Not an addition or whatever, but I still wish that they would change this because the answer doesn’t match the question. The answer is lifted directly out of the PCI-DSS Top 10 Myths addressing the need for a QSA to be involved in the process. The answer is , it is recommended, but NO, for Level 3 and 4 merchants, there is no requirement to get a QSA involved.

Finally, a bonus opinion here.

Many agencies are still faltering in their PCI-DSS compliance. Some equate that just because they are level 3 and 4, they do not need to do ASV scans or penetration testing. Likewise, there are those who *might* theoretically (we don’t know any) qualify for level 1 or level 2 based on their volume, automatically assume they need to do ASV scans and do pentest for everything in scope.

NO.

Your merchant level DOES NOT dictate whether you need to conduct PCI scans or not. We need this to be clear. Because the table published in the FAQ from IATA for FAQ#13 isn’t clear (not their fault, this was lifted from the Mastercard site) – the column “Validated By” states ‘merchant’ and below “Approved Scanning vendor” for level 2 and below. This immediately presupposes that an ASV must be involved. This is incorrect.

Your level (determined by your card transaction volume) determines your VALIDATION TYPE. Validation type there are 3: QSA Certified/Validated; Validated SAQ by QSA/ISA and SELF SIGNED SAQ by MERCHANT OFFICER. That’s it. Your level doesn’t determine how you go through PCI, it determines how it is validated. And it’s not set in stone. Your acquirer can bypass these guidelines and decide that even if you only do ONE transaction a year, you still must go through level 1 compliance (audited by QSA). This is actually quite common!

So what actually determines what on earth you actually do in PCI-DSS?

Well, it’s your business. Or, for Level 2 merchants and below, your type of SAQ. You see, it’s your business that determines your SAQ type, it’s your SAQ that determines what you need to do, and based on what you have done, it will be validated in either of the 3 ways we’ve described above. That’s the harmony of PCI. That’s the zen. The yin and yang. The balance in the Force.

So, for instance, if you are doing SAQ A, SAQ B or SAQ C-VT, please point out to us the fact that you are REQUIRED to do ASV scans on all your internet address (some are told, even their dynamically allocated broadband IP must be scanned by ASV).

None. Magically, SAQ A, SAQ B and SAQ C-VT DOES NOT HAVE ANY requirement for ASV or penetration testing. For us who can provide these services, of course it kind of sucks since now those going through these SAQs don’t need our services anymore. But we rather tell them straight the correct way and sacrifice that part of our business than to let them know wrongly and give consultants a bad name. So what SAQ you are doing will determine whether you need to get something scanned or not.

Now, of course, do not be tempted to fit your business into the easiest SAQ for the sake of it (see the example of travel agencies with GDS doing SAQ A) – there are huge eligibility requirements for these 3 SAQs and not many agencies can meet it. If you practice accepting cards through email, or photos on Whatsapp for your credit card; or store in back office for later processing, or have Enhanced Data Services from Visa/Mastercard or a thousand other ways you can be receiving credit card, you likely need to fit back into the dreaded SAQ D. But what we are saying is that if you ARE eligible for A, B or C-VT, then those will determine whether you need to do any testing or not.

It is our opinion that testing and scans should be done regardless for security sake, not so much for compliance but the choice is yours. You need to make that decision for your own business. Because that’s what heroes do.

If you have further queries on PCI-DSS or just how we are currently helping our clients get through PCI, drop us an email at avantedge@pkfmalaysia.com. We will respond ASAP!

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!

« Older posts

© 2024 PKF AvantEdge

— Up ↑