PKF AvantEdge

Tag: iata (Page 1 of 2)

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: Why your SAQs Matter

October 25, 2017 / / 0 Comments

We have had a few discussions among consultants as we progress further into this compliance for our Travel Agency clients. And very often (if not always), the matter always comes down to, “Can we just do an ASV scan and you certify us?”

We have touched this topic many times. ASV scans cannot certify you as PCI compliant. They are just one of the requirements. In fact for some of the SAQs (self Assessment questionnaire), ASV is not even needed.

SAQ A

We’ve gone through the famous SAQ A in our last post. This is basically where no card data is being entered in merchant environment and they basically forward everything over to the payment provider. There is no requirement for ASV. That doesn’t mean it makes it right though. Imagine this scenario: the developer makes a hopeless job at coding their web application. There are two ways SAQ A can be done: redirect or iframe. Let’s recap.

A redirect occurs when the merchant website sends a redirect instruction to the client browser when payment needs to be made. This instructs the client to connect directly to the payment gateway. This instruction could be a simple

onclick="location.href='https://payme.com';"

Or similarly through some javascript with window.location.

The iframe is similar, whereby a ‘child’ window is called directly from the payment gateway and has a window in the main merchant site. Although everytime this occurs, I have nightmares of those old websites with scrolling words, flashing lights and like 5 – 10 frames running at once. Netscape days.

iFrames are simple as well, with the site you want to call embedded within the <iframe src> tags.

So, anyway, back to ASV scans on these merchant sites. Although its not required, if the web application itself is poorly constructed and is compromised, there could be a high possibility that the redirect process itself gets hacked and redirected to another site that looks like the real payment site. You can imagine what happens next. The solution here is to ensure even on the merchant site, this site is developed with good secure coding practices. If ASV is not required, it does not mean you don’t need to run any scans. We would recommend vulnerability scans to still run against it, whether ASV or not. In fact, any web facing system out there should be tested – because if you are out there, it’s open season – anyone can attack it, and it’s up to you to secure it.

Conclusion: No need for ASV, but recommended – if not ASV, at least some security scans.

SAQ B 

Ah, the good old SAQ B. A lot of people misunderstand this for a good reason. Some of our retail clients, or F&B clients insists this is the correct one as they are using card terminals. However, they forget that most of them have their integrated POS systems – specifically because they need to charge an amount like food etc. So their POS systems sends these details to their EDC (Electronic data capture) terminals and the EDC accepts the DIP cards. What happens is that, these EDCs sends back the transaction data and in many cases, they still swipe our cards on the payment system. SAQ B doesn’t qualify here. SAQ B is specific for dialup EDCs directly to acquirer bank. For those using 3g/4g, then these can be considered as well. If you are using WIFI, or internal broadband link then you are out of luck. No SAQ.

Because of the direct point to point or cellular connectivity, ASV is not required (for a good reason!)

Conclusion: No Need ASV – IF you actually qualify for the SAQ that is.

SAQ C-VT

Another difficult SAQ to be eligible for. It has very specific requirements – whereby a web-based browser connectivity to a virtual payment provider who is PCI compliant. I think it really applies more to hospitality or travel agencies. In this case, the question is often asked – what about my broadband IP accessing the net? Because for sure, when I connect to my virtual terminal provider, I am using the internet right, and not leased line or any point to point? So for sure, my broadband has an IP. Just type “whats my ip” in google and it will show. Most of them have dynamic IP addresses as well. In SAQ C-VT there is no requirement to ASV scan.

However, having a dynamic IP and no ASV scan in SAQ C-VT doesn’t mean you still can’t do it. Many routers/firewalls are poorly implemented or poorly patched. We would recommend to do an internal scan on the firewall interface to ensure vulnerabilities are identified. Again, it’s a matter of securing the internet exposed system.

Conclsuion: No Need ASV, but we recommend an internal security scan on the firewall to ensure the box is properly hardened.

So, there you have it. It’s critical to know your SAQs so you know the extent of what NEEDS to be done and what is BETTER to be done than not.

If you need assistance with your PCI-DSS, drop us an email at pcidss@pkfmalaysia.com

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!

IATA PCI-DSS: Approaching the BSP Channels

August 26, 2017 / / 0 Comments

First of all, Selamat Hari Merdeka (Independence Day), and congratulations Malaysia for hauling in a record number of SEA Games Gold Medals. So much so that our government has declared next Monday (4th September) as a holiday for….celebrating? I am all great with achievements, but at the risk of sounding like a spoil sport – aren’t we having a wee bit too many holidays? It’s great for morale I suppose, but it’s not so great for business due to the start-stop nature of things and worse, when we are chasing down a compliance deadline for our clients. In fact, approaching the end of the year, the amount of compliance work we are faced with is absolutely daunting.

Which is why it has taken so long for an update on this blog – not because it is low priority, but because we were just chasing so many deadlines in August, and now in September all the way to Christmas. It’s going to be a fun ride to the end of this year for sure.

Now as we approach our March 2018 deadline, we are getting more and more travel agencies calling us up on the IATA PCI-DSS requirements. While these are generally smaller agencies, we have come up with a standard package that addresses specific agencies with specific requirements.

a) No storage of PAN electronically

b) Only for Level 4 merchant levels (less than 1 million traditional transactions and less than 20K Ecommerce transactions)

c) Self signed SAQ by Merchant

d) GDS (Global Distribution System) Provider must be PCI Compliant

These are reasonable conditions for us to consistently approach each agency. See the problem is not so much that travel agencies are complicated – it’s because we have a whole lot of agencies with a very short deadline. We advocate that the whole industry and QSAs, Consultants or PCI experts all work together to get these agencies up to speed.

The first hurdle of cost prohibition is passed. Previously we all thought (based on the wordings) that IATA requires all agencies to have the QSA sign off on section 3c of the SAQ/AoC document, effectively rendering all Level 4 merchants to be Level 2. Obviously that would cost more as Mastercard requires Level 2 assessments from QSAs to be carried out onsite as opposed to remotely. That won’t be feasible due to the amount of agencies. Once it becomes more of a consultancy and advisory as opposed to an audit, it makes more sense. We are not saying QSAs should not get involved – we are saying now agencies have more options on their table – if QSA is affordable then by all means.

Secondly – storage of PAN. This is a real pain. Especially for travel agencies. You may think that you don’t store the PAN, the infamous Primary Account Number, that 16 digit on your credit card (remember, truncated PAN, or what we know as “First Six Last Four” or “Last Four” where the other numbers are X’ed out – this is NOT PAN)- even if you don’t formally store PAN as your process, the fact that you receive PAN in email, or Whatsapp or Skype or Wechat or QQ – anything at all – this translates to PAN being brought into your environment. Unless you are interested to secure your handheld devices and laptops and desktops and email servers – we suggest that you have only formal channels of card acceptance. Via Phone is one way. Through a secure portal is another way.

The problem is compounded due to Credit Card Approval Forms (CAF) or Credit Card Charge Forms (CCCF). These are formal forms either from the agency or from IATA to collect details of transactions, inclusive of credit card. IATA, however, has taken pains to ensure their channel is PCI certifiable and has since removed the requirement for CCCF to contain credit card information in full, as well as providing electronic alternative to CCCF submission via GDS. They are, in essence, securing their channels.

What about travel agencies own CAFs? This is not in any regulated form and even sometimes we see CVV information being required in these forms. This obviously is not allowed, to the genuine surprise of some agencies. Like the CCCF, either these forms need to be secured, or the channels in which information is provided needs to be secured. This is one of the challenges being faced.

Thirdly, the fact that IATA allows for self signed SAQ eases up the pressure of getting an audit in. However, in theory, the agency still needs to go through the same amount of due diligence to ensure they are fully compliant. Audit or no audit, there is no excuse of marking down “Compliant” in the SAQ for a question that you have no clue about. One client actually marked down compliant for “IDS” thinking this meant Internal Distribution System, which he thought was another name for GDS. Seriously. We don’t blame them. We blame the entire technology community for coming up with these acronyms that can sometimes be frustratingly flabbergasting for the general public to understand.

Lastly – the GDS. The ones we have experience with are Sabre, Travelport-Galileo and Amadeus. We come across some older ones but in general, these are the three main ones utilised by travel agencies. All of them as far as we know are PCI-compliant. We only have ever seen the AoC from Travelport. Sabre and Amadeus in turn provides our clients with some weird certificates by QSA or other documentation that is not AoC. Again, it’s just completely irritating when providers give these so called ‘certificates’ and argue with us that this is acceptable to PCI and we have no idea what we are talking about. It’s mind numbingly, teeth-gnashingly frustrating.

The GDS channel is general is secured. As long as credit card information is sent to the GDS mainframe you are more or less done. The problem is whether the desktop client is an actual application or just serves as a web gateway to the mainframe. This is where we are juggling between SAQ C or SAQ C-VT for this channel. We have gone through the Sabre Red Workspace and Galileo Desktop, and either of these cannot function without internet connectivity, and all information traverses through a TLS link to the mainframe of the GDS. We have done packet capture on these applications and while not traditionally considered as ‘web browsers’ in what we are used to, the functionality of it is similiar to a web based client. Even Travelport AoC states that the ‘travelport application client’ is covered under its compliance. In essence, these are virtual terminals in every understanding of the term.

While rare, the internet channel is probably the most straightforward, whereby an SAQ A should sufficiently cover most agencies, since they are utilising a payment gateway and not processing, transmitting or storing credit card information in their own environment.

In summary, the challenges faced mainly by agencies is not so much on the security of BSP or GDS channels, but their own. The credit card forms remain a pain, not so much of the forms itself but the channels in which the forms are sent or received. This forms a very real challenge in securing based on PCI-DSS requirements.

Of course, we have also recently encountered another massive hole in the travel agency PCI program – if you are doing “enhanced data services” with any of the card brands and exporting through a system like Sabre Powersuite, you have another headache in your hands: Clear PAN. We will go into this in a later post. Suffice to say, we have a lot to do, with little time to do so, so it’s time to get cracking.

Drop us an email at pcidss@pkfmalaysia.com and we will see how to get you started with your PCI-DSS program.

 

« Older posts

© 2024 PKF AvantEdge

— Up ↑