Tag: bsp

IATA PCI-DSS: Approaching the BSP Channels

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.

 

IATA PCI-DSS: What Exactly is Required?

pci-compliance

Continuing our series on Merchant program for PCI-DSS. Why this is (or will be) so important is that in around 12 – 15 months, if you are a merchant, very likely you will be getting a call from your acquirer.

About 2 months back, Mastercard announced that all acquirers must have in place a risk assessment program for Level 4 merchants by March 31, 2019. This basically means that there is a great concern that 99% of Level 4 merchants out there are blissfully unaware of this PCI-DSS nonsense they need to comply. It is the acquirer’s duty, but the pain starts all the way at the merchants.

One industry feeling the pinch here is the travel industry. But don’t worry, travel agents, soon, the other industries like your cousins at the hotels and hospitality will be going through the same process as you are going through now. It’s just who is going through first. And the faster you get through the better.

Travel agents across the world has been mandated by IATA to be PCI compliant. Please read our previous post here.

We have gone through the requirements in that post, but we’ve been hearing a lot of things coming to us from the travel agencies recently, namely:

a) All Travel Agents need to engage a QSA to formally sign off their SAQ.

IATA should be able to give a formal statement on this. QSAs or consultants or PCI experts cannot dictate or mandate the validation requirements. Mostly this is by the processor (IATA) or the acquiring bank. If they can’t make a statement, then it would fall back into the card brand validation requirements. Which it has so far, unless IATA comes forward to clear this up. We can’t seem to find anywhere that IATA has had special requirements other than listed in the card brands requirements.

There might be further explanation needed based on their PDF at http://www.iata.org/services/finance/Documents/pci-dss-compliance-procedure.pdf

The procedure first states

Travel Agents are encouraged to contact their merchant bank (acquirer) or the applicable payment brand(s) to identify the appropriate procedures based on their eligibility.

But then at the bottom it implies that for assessment, it needs to have a QSA perform ‘on-site’ PCI assessment – which is not exactly accurate as it depends on their level. Further on right at the bottom, it states:

Depending on the number of card transactions handled those can be:
– PCI DSS Attestation of Compliance (AOC) which must be completed by a Qualified Security Assessor (QSA).
– Self-assessment questionnaire signed by an authorized officer.
– The results of quarterly vulnerability scans if applicable.

The problem here is that if the AoC is required to be signed by the QSA, so does its corresponding SAQ. These documents have the same signoff (3c for QSA) section. If you read the above you might be tempted to also argue that IATA is saying, depending on the number of card transactions (meaning your level), the requirements can be either:

– PCI DSS Attestation of Compliance (AOC) and ROC or SAQ which must be completed by a Qualified Security Assessor (QSA) – this applies to Level 1 Merchant (they can also use ISA but lets put that aside for now), and also Level 2 if you deal with mastercard.
– Self-assessment questionnaire (SAQ) and AoC signed by an authorized officer. – This applies to level 3 and 4
– The results of quarterly vulnerability scans if applicable.

Now we don’t know if this is what IATA is saying – it’s just the many ways this section can be interpreted so we do hope IATA will have a clarification on this matter. They CAN decide on a more stringent requirement for their agencies (such as ALL levels engaging a QSA to be onsite like a level 1 merchant), but this needs to be clear, so agencies can forge ahead with the proper budget and expectation.

Most travel agents fall under the Level 4 category of merchants, which based on the current requirements of PCI-DSS only requires a merchant officer to sign off the document.

Mastercard’s SDP services recently responded back to us on this with a confirmation as below:

Level 4 merchants are required to ensure they are PCI-DSS compliant by filling in the correct SAQ based on their processing environment and have the evidences prepared , and also to do this each year. There is no requirement from Mastercard to engage a QSA/ISA to signoff their SAQ on part 3c or part 3d of their SAQ/AoC and their executive signoff on part 3b is sufficient. This must be signed by the merchant. Engaging a QSA will be above and beyond their requirement and only done if they require assistance in filling their SAQ. Therefore, using a QSA is entirely optional and based on the discretion of the merchant.

This goes a long way in saying the same thing that has always been said. The logic I would argue here is, if your industry is made up thousands of merchants, how do we build a meaningful program to get all these merchants compliant? If QSAs are supposed to validate all the evidences, how much bottleneck will there be?

This is also inline with the famous PCI-DSS myth document at https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf. In Myth 6:

Myth 6 – PCI requires us to hire a Qualified Security Assessor
Because most large merchants have complex IT environments, many hire a QSA to glean their specialized value for on-site security assessments required by PCI DSS. The QSA also makes it easier to develop and get approval for a compensating control. However, PCI DSS provides the option of doing an internal assessment with an officer sign-off if your acquirer and/or merchant bank agrees. Mid-sized and smaller merchants may use the Self-Assessment Questionnaire found on the PCI SSC Web site to assess themselves.

Now, I know, there are so-called ‘merchant programs’ out there run by a few QSAs. I’ve spoken to many merchants who deem themselves compliant just because an ASV ran a scan on their external IP address and gave them a ‘certificate’ of compliance (which is not even a recognised document by PCI-SSC!).  If anything, it just makes the merchant falsely complacent and gives PCI a bad name and a bad rep as an on-paper compliance but practically as useful as ice is to eskimoes.

The crux of the matter isn’t whether QSAs need to be involved or not. It would be super if they can get involved, but the matter is cost and time. QSAs programs are not cheap, and also, how much work do they actually do for the client? The counter argument is, if QSAs are not involved, what then? You get a bunch of executives just signing off they have a firewall when in their mind they are thinking, “Man, Which wall am I going to have to set on fire to comply to this stupid request?”. It’s not a knock on their intelligence, but really, a lot of merchants are really good in doing whatever they are doing and they don’t exactly have a CIO to standby to interpret all the requirements of PCI-DSS for them. And PCI, despite its oftentimes banal requirements, is a compliance requiring a lot of technical understanding.

How do we solve this? Awareness.

The SAQs reason for existence serves simply as a baseline document and puts the onus on the merchant to ensure they have the proper security in place. A lot of merchants are not aware of this obligation. The moment they sign off that document, they are saying, I am taking responsibility over this document. I verify and validate this as true. If it’s not…well. If it comes to any breaches or anything, then the merchant takes responsibility.

If they are fully aware of their responsibility, then getting help is likely required. But now, there is no need for a formal QSA to get involved. If you can, then do so as QSAs do theoretically should have more experience in PCI – but consultants, or advisors can take this role. And there are many reasons why it might turn out better this way which I will explore in my next few articles.

b) All Travel Agents need to engage ASV to do their security scans

Man. This is probably the most misunderstood requirement of all time. All time. 100s of merchants have come to us proudly saying their ASV scan proves their PCI compliance. No, it doesn’t. The ASV scan is just one of many requirements you need to go through. It’s like you dressing for work and wearing only your shoes and nothing else and go to work and say, “Hey, I am all dressed!”. Um. No.

And while ASV is important, we have seen our fair share of trigger happy ASVs being done for travel agencies. Oh, you have a website? ASV! Oh, you have an internet facing IP and router? ASV!

Come on. We recently adviced one client who was having trouble remediating an issue on their website. I asked them, wow, for a small company doing internet transactions, its a big deal. And they went like, “What in the good name of **** are you talking about?” And they explained they just had a corporate website and were asked to do a scan. I went and look, and aside from the site looking like it had been designed by a 15 year old drinking too much mountain dew, it serviced no credit card transactions at all. They don’t even have any systems doing that. They just do EDC terminals that connect directly to the bank and completely isolated. So why the scan?

Because we were told, they said.

And so I drafted an email for them and told them to send it over to their QSA (they are level 4 by the way) and the response came back, “Oh thanks man, they told us there is no need to scan anymore! Yay!”.

The problem remains. How many merchants are scanning their completely static websites and receiving a certificate of compliance and pronouncing they are PCI ‘certified’? Is it the ASV or QSA’s problem? No. PCI clearly states that it is the merchant (or scan customers) who ‘defines the scope of the scan’, so merchants are taking a fair bit of the burden if the ASV is done incorrectly. ASV scans are needed if your site does credit card acceptance (SAQ A-EP). It’s also needed on any external IPs you might have if these are transmitting card information (SAQ B-IP, SAQ C). SAQ A, B and C-VT has no scan requirements listed. A lot of clients could possibly fall under the SAQ B and possibly SAQ C-VT, so ASV scans can be further avoided.

c) All Travel Agents will be fined XYZ amount for non-compliance

Now, this might be true but IATA hasn’t really come out to say anything. Frankly I will be very surprised if there is such a requirement. Basically, IATA is just saying, if you don’t become compliant, don’t connect to us. If you don’t connect to us, then you can’t issue tickets. This is a worse threat than being fined. So they don’t have to be overbearing to impose such a condition AND impose a fine for clients who are non compliant. Because technically, if you are non compliant, you are not connected to IATA. If you are not connected to IATA, what are they fining you for?

smartmurphy

d) PCI-DSS is applicable to all Travel Agents even those without credit card acceptance and transactions

OK. I am not sure whether there will be such agencies or not, meaning there is ZERO card acceptance or processing or storage or transmission in your merchant environment. Now do note, even e-commerce when you outsource your ENTIRE payment processing, the fact that you have the credit card payment option on your website puts you in need of compliance. For merchants that do not have any facility whatsoever (either card present or card-non-present), then technically, PCI-DSS should not apply. I say technically. Because if you are connecting to IATA’s processor (BSP) then even if you make zero or a million transactions, the risk is still there. So yes again IATA as the big boss of BSP has the right to ask for compliance from agencies with zero credit card transactions. In this case, my suggestion is to write to IATA  and see what is the next step. I can’t imagine any merchant business now not catering to credit/debit card payment but, wait. OK, my neighbourhood barber actually told me they only accept cash only, or barter trade my iphone for 2 years supply of haircut. So yeah, why not. But really, if no credit/debit card payment is an option and you regularly settle through agency credit or carrying a pile of cash, you technically can ask IATA what’s the next step.

In summary, we are not saying that there is some sort of conspiracy theory going on where QSAs are trying to pull a fast one on customers and creating F.U.D in the industry. After all, we ourselves have been certifying clients for 7 plus years already. But what we need to understand is that wrong information could be worse than no information. We need to get the right information out there so that merchants can make informed decisions. If they want QSAs, then ok all the better. If they prefer in house or specialised consultants, then OK. If they decide to do the hokey pokey instead of PCI compliance, then hey, that’s an informed decision on their side.

So, let’s get this awareness out. Travel agencies have about 10 months to get compliant. It’s not crunch time yet. This is like the start of the 3rd quarter in basketball. Important, but not Michael Jordan clutch time.

If you need more information on PCI-DSS applicability in your merchant business, drop us an email at pcidss@pkfmalaysia.com. We’ll get in touch with you ASAP.

© 2022 PKF AvantEdge

Up ↑