Tag: compliance (Page 4 of 5)

PCI-DSS IATA: Dissecting the New FAQs

A few significant things occurred this week for the IATA PCI-DSS Program, summarised below:

a) We finally have a very clear way forward thanks to some clarifications direct from IATA, and in some parts due to our dogged persistence to get some answers

b) The new FAQs were published end of June and an updated version was done yesterday (11 July) and is now online at http://www.iata.org/services/finance/Documents/pci-dss-faqs.pdf

Firstly, the significant news.

IATA confirmed that Level 3 and Level 4 Merchants do not need a QSA to signoff their AoC/SAQ – which, to many agents, means they can do SAQ on their own, or using their own IT resources, or external consultants (not necessarily QSA, but if you prefer a QSA, by all means, go for it)

IATA also confirmed that they are considering exemptions for agencies that do not have any credit card transactions in their business channels.

These two clarifications address some long running questions agencies had for PCI-DSS. Do they need external consultants, do they need a QSA, do they need any compliance even if they don’t have credit card, etc etc.

Regarding point b) above, there was a quick iteration on the FAQs to clarify a few items. So here are some of the changes between the newest FAQ on 11 July and the one on the 29 June, and we can go through it.

The first 4 FAQ questions remain more or less the same although we do have a nitpick on 1, which is

FAQ#1 Who do I approach for PCI DSS compliance?
We suggest that you contact your acquirer.

Technically, this is correct, however, it’s not exactly complete. Because their (travel agents) acquirer wouldn’t have visibility over the agencies’ channel of credit card via GDS and BSP (or soon to be NGI – the new gen ISS). Acquirers have no idea of this because when the agents uses GDS credit card facility, they are doing in BEHALF of airlines! So even if they were to correspond with the payment brands directly as per FAQ#3, the brands wouldn’t know, nor care about the agency. Because in the GDS-BSP channel, the agency is not the merchant – it is the airline. (lightbulb).

Therefore, it must be the airlines who must be PCI compliant in that channel – however, because they make use of agents, the agents end up having to be compliant as well. But the airlines don’t deal directly with agents for this channel – they have an aggregator in between the agencies and airlines. And yes, this aggregator, this glue that holds everything together is the ecosystem of GDS-BSP/NGI. So if the agency connects to BSP, IATA is the ‘service provider’ offering this service – therefore, it is IATA that needs to clarify the requirements. Which they are doing – so technically FAQ 1 should read

FAQ#1 Who do I approach for PCI DSS compliance?
Yo, it’s us, man! That’s why you’re reading this on an IATA page!

In our clarification request, we didn’t point this out to IATA because our email at that point was already too long. It’s like we were writing the Titanic of emails, and we had to cut some scenes to fit into a readable email size.

Next, FAQ #6 is also important. Only for our own selfish self satisfaction.

FAQ #6 Are compliance certificates recognized for PCI DSS validation?
The answer to this question is no. Any sort of documentation which is not under the authority and validation of PCI DSS, will not be accepted for indicating the company’s compliance with PCI DSS.

And this is what we have been telling clients for YEARS. There is literally no such thing as a certification of compliance as far as PCI is concerned. Yet, everyone wants to see your ‘certificate’ and even go as far as to reject the AoC and RoC and SAQ documents. There is NO SUCH THING as a PCI-DSS compliance certificate. If someone prints a certificate out for you, it cannot bear any logo from the PCI-DSS council because it is not part of PCI. It’s a nice piece of paper to put up in your lobby but that’s it. When we work with our principal QSA, they also have this “certificate”, but we always make it clear that this is only issued as an aesthetic by the QSA and not considered acceptable to the PCI-DSS program formally. You MUST have the AoC and RoC/SAQ combination of documents at least – and also whatever ASV scans etc you might have. So, we would suggest not to go about calling yourself PCI-certified agency – just say you are compliant to PCI is enough. It sounds less sexy but those are more accurate terms to use.

FAQ#7 was corrected to refer to Question 14, instead of Question 13 as previous FAQ stated. Innocent error, of course, no harm done. It doesn’t mean that the writer of the FAQ can’t count.

FAQ#8 was also corrected whereby the previous FAQ stated (emphasis ours)

“The latter has to be completed as a declaration of the results of the service provider’s assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS).”

and now correctly states

The latter has to be completed as a declaration of the results of the merchant (or travel agencies)’s assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS).

Because technically, travel agents are merchants not service provider, so it might be just a copy and paste error.

FAQ#11 Can a QSA that is not listed in a specific country but listed in another country conduct a certification process in the non-listed country?

Originally it stated

“Yes. By definition, Qualified Security Assessor (QSA) companies are independent security organizations that have been qualified by the PCI Security Standards Council to validate an entity’s adherence to PCI DSS.”

This might not be exactly accurate as there are certain regional restrictions based on fees. So, the change became

“Overall speaking, yes. Nevertheless it should be noted that under the QSA program guide, section 6.3.1, there are qualified regions in which QSA can or cannot perform in as noted “QSA Companies are authorized to perform PCI DSS Assessments and QSA-related duties only in the geographic region(s) or country(s) for which they have paid the regional or country fees, and as indicated on the QSA List.”

Once again, that’s more accurate. And there are more words. And it has a quote from an official document from PCI, so it sounds very important.

FAQ#14 has the big change in the new FAQ version compared to the one in June, whereby under level 2 merchant column we have this “note” to clarify that level 2 merchants under Mastercard requires either an onsite ISA or onsite QSA to validate their SAQ. This is what we call “Validated SAQ”, and this is what Mastercard was telling us earlier, that this must be done by the QSA onsite (if they do not have an ISA – which is “internal security assessor”, which is as rare as an albino beluga whale).

FAQ#18 is the one applying to agencies without any credit card transactions. Now you do need to be careful. IATA does state that PCI applies to agencies processing credit card with the IATA GDS-BSP channel or any other channel (including your acquiring bank direct channel). This means if you have an EDC or POS device, or do internet transactions, you STILL need to undergo PCI-DSS. Who you send your AoC/SAQ to is another story, because IATA wouldn’t know much about your POS/EDC channel since you are not their merchant. Technically you send it to whoever you have a merchant account with – your acquirer. But again, your acquirer isn’t even asking for it! So. We suggest that you still do it, and keep it in case someone asks for it. We hear some cynical snorts in the background but we are going to ignore it. Be nice.

FAQ#23 – they decided to completely change this one. The previous answer seemed slightly confusing and in contradiction to FAQ#6 and FAQ#14. Previous FAQ in end June stated:

It should be noted that the third party should be authorized by the PCI DSS Council as a Qualified Security Assessor (QSA) to accept the PCI DSS compliance certificate. The scope shall cover the BSP card sale transactions.

a) Again, as FAQ#6 already confirmed – there is no such thing as a compliance certificate, so technically all compliance certificates issued by whoever, whether QSA, ISA, consultant or the Queen of England should not be accepted as formal documentation of PCI. One more time we hear this certificate of compliance being bandied around like its some sort of Ark of the Covenant, we are going to collectively walk out of our office and lie down on the main road in silent protest.

b) It’s sounds slightly confusing because it seems that this statement is saying a QSA is needed to be involved for all merchant level compliance as well which is contradicting FAQ#14.

To give them credit, their explanation to this was:

“We have had instances in which the agent was providing us with some sort of certificate issued by a third party, under the assumption that the certificate was issued by a QSA therefore we wanted to make clear that in the case an agent were to go this way they should be checking out the authorized QSA list available in PCI DSS council site.”

Yes, completely agreed. But not the certificate part. D@mn it, that’s it! We are headed out tomorrow and lying down on the street in protest!! Watch the news!

Anyways, now the current FAQ#23 reads a different:

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, for Level 3 and Level 4, 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.

If this sounds familiar, it’s because it is. It’s lifted from Myth 6 in the famous PCI document at https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf

It’s certainly reads better, although, it doesn’t really answer the FAQ#23’s questions, but hey who cares? It makes sense!

So anyway, from this we learnt a few things

a) IATA is really keen to be on the ball on this PCI-DSS compliance and has put in effort in getting the right information out to the agencies – kudos to them and really impressed with their management’s response to queries.

b) The industry as a whole is still grappling a lot on PCI-DSS and needs to move forward with the right information and decision.

c) As QSAs, consultants, auditors, advisors or IT experts, we all need to work together to get our clients up to speed with the right information so they can make decisions and we can assist them.

PCI-DSS is never easy. Even those doing SAQ A-EP are having headaches, what more agents going through SAQ D-MER and all its 340++ questions. IATA seems to understand that and has PCI on their agenda.  We are willing to work with anyone on this – we have our clients who are travel agencies, but we also want to help other agencies get up to speed with PCI, what is required, and how to get compliant from the different validation requirements per PCI’s standpoint.

So to summarise this long winded post, from the horses’ mouth themselves:

a) There is no need for QSA involvement in Level 3 and level 4 merchant self assessment questionnaire (SAQ). Merchant officer signoff on section 3b is enough. However (and this is our opinion) if you can get assistance from QSA, ISA, consultants, IT experts, auditors,the Queen of England or even your own internal IT person familiar with PCI, go for it. You’ll need all the help you can get.

b) For those without credit card transactions in ALL channels (not just IATA), consider the exemption in FAQ#18. But please contact IATA on this as you should truly understand what might be the consequences in the future.

OK, that’s it for now. Drop us a note at pcidss@pkfmalaysia.com. We are preparing a complimentary talk on PCI-DSS specific to this travel agency industry soon, so stay tuned!

IATA PCI-DSS: Who is doing what?

pci-compliance

We have been receiving a ton of emails and inquiries lately ever since we started marketing our services for PCI-DSS to travel agencies. It has to be noted that some of these travel agencies were our clients to begin with. PKF has a very large set of customers because we do the entire end to end corporate services. We are not just one technology advisory firm. We have tax advisory, business advisory, internal audit, external audit, outsourced, accounting, corporate finance, forensics accounting etc. So over the course of 20+ years we have amassed a ton of clients and many of them are travel agencies, whether in technology group or in others. This is where our main queries stem from. Existing travel agencies are querying us and in turn they are letting others know about us, so much so that we are now compiling an FAQ to address all questions being thrown at us on PCI-DSS.

One common question we get asked is: WHO is initiating this PCI-DSS?? We even get accused of being the ones initiating this PCI-DSS on them and planting a deadline of March 2018 for them.

So let’s get the story here straight. For this, it is necessary to go from the beginning to the brief history of PCI.

a)  PCI-DSS began its life in 2004 but only in 2006, PCI Council was formed to govern this standard. The council is now made out of card brands Mastercard, Visa, Amex, JCB and Discover/Diners. The purpose was to ensure there was a standard way that merchants/service providers can secure their credit card interacting systems to, instead of to each individual card brand’s compliance. It’s a good thing. Basically the whole idea is to ensure the whole ecosystem where credit/debit card is used/processed/stored/transmitted is secured.

b) IATA’s story probably began back in 2015 when, according to GDS Amadeus, VISA Europe issued a deadline to acquiring banks using its network that all airline merchants should be PCI-DSS compliant by 31 December 2017. So the airlines got into a huff and took a look at their processes, which is like any other merchant – they have their acquiring bank to do the authorisation, clearing and settlement. So far ok.

c) However, the airlines had one problem: Indirect distribution channel. This is where airline tickets are distributed via travel agents, either through walkin, MOTO or internet. Travel agents use a GLOBAL DISTRIBUTION SYSTEM (GDS) that link to airlines to check for ticket and also to financial institutions for authorisation. And these finally link to IATA. Why? IATA has the Bank Settlement Plan (BSP) to – yup you got it – facilitate the clearing and settlement. BSP allows many travel agents to connect to many airlines, allowing a one stop shop to ensure everyone gets what they want, instead of travel agents separately dealing with airlines and vice versa. It’s orderly and it helps the industry.

d) However, the BSP, due to its connectivity to the Airlines now needs to ensure its downstream connecting parties are also PCI-DSS. Cue, travel agents and this is where IATA tells the travel agents, look, get your act together because the airlines need to be certified, so we need to be compliant, so you need to be compliant.

So in conclusion, it is IATA initiating it to the agencies – because there is an upstream push for them to be compliant. It’s common as well – many times payment gateways are asked to be compliant by their bank – we hardly see any entity embarking on PCI-DSS just because they feel that it’s the best thing to do for them. But the overall initiator of PCI still remains the card brands – whether it is VISA, Mastercard or Amex etc.

Now the question here is this – because IATA is considered a processor (with their BSP), they are enforcing a deadline of March 2018. At the same time, they also need to provide a way for agencies to submit the compliance document.

It’s a bit confusing here, because Agencies are also merchants in their own sense. They also have their own channels to collect payments, and some payments are made directly to their merchant account, and they settle with IATA through cheque/cash/bank in etc, not via card. Everytime a card is entered in the BSP, the agency is acting in behalf of the airlines using the airlines merchant ID. Everytime a card is used in the merchant’s own environment such as POS, EDC or Internet, the agent is the merchant, and they do authorisation, settlement etc through their own bank. IATA/BSP is not involved in the credit card flow in this case.

However, because IATA is requesting PCI to be adopted by agencies, agencies also need to look into their other channels that do not involve IATA! So imagine, an agency does their SAQ C/C-VT and sends it over to IATA, but to cover their EDC or terminal business, they do an SAQ B – who on earth do they send this over to? Well they send it over to their own acquiring bank. Their bank asks: Hey, what the heck is this? Well, it’s our PCI Compliant SAQ/AoC, Mr Bank. And Mr Bank is happy but somewhat confused and asks: Why are you doing it anyway? I didn’t ask you to do it yet because you only do 1 – 2 transactions with us. (Please note, even if it’s 1 – 2 transactions, you are still considered a Level 4 merchant, but most banks are ensuring their large volume merchants are compliant first). So therefore, agencies have two upstream processors to send their PCI documents to – IATA (for IATA channel) and their own bank, for others.

In the next post, we will explore on the validation requirements and why its so important to know what validation requirements apply to you and how. Do drop us a note at pcidss@pkfmalaysia.com. We are having a bunch of queries, but we will answer you ASAP.

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.

The SAQ Bs and how they apply to you

pci-compliance

We always say SAQ As and Ds get all the glory and attention.

This is because a majority of our SAQ clients are e-commerce companies and therefore they apply SAQ A or A-EP depending on where their credit card information is collected.

However, recent times, we have been working on a well-known retailer and were told that SAQ D would be the one that applies to us. Now the SAQ was passed to them by the bank and the bank insisted that they do SAQ D-Mer.

Now this post is going to assume that you have some working knowledge on what SAQ’s are in PCI-DSS world. Self Assessment Questionnaires are one of the most misunderstood concepts in PCI. They are like Donald Trump’s foreign policy and the plot of Interstellar all mashed into one misunderstood mess. Often because acquirers find it so hard to understand, they just tell all their merchants that they should go for SAQ D.

Now we have fought for our clients before – where we overturned the acquirer insistence for one of our e-commerce clients to do an SAQ D-Mer, and instead got them to agree that an SAQ A-EP is sufficient. SAQ A-EP = around 140 questions. SAQ D-Mer = around 320 questions. Big difference.

Why is this important? We firmly believed in the concept of overdoing PCI is not a good thing. Why? Because our clients have other things to do and limited time and money to do these. Ideally, sure, everyone should go on Level 1 Certification. But the reason why the PCI Council created a whole bunch of ‘levels’ and then types of SAQs is simply because different businesses face different risks. It doesn’t make sense for a neighbourhood grocery that accepts 10 cards a month to implement the same million dollar controls as, say, Tesco or Exxon Mobil. So. Don’t overdo things, but don’t under-do it as well.

Back to SAQ Bs. So with this client, after talking to them a few rounds we found out that:

a) Their credit card terminals are separate and not integrated with their POS machines and connected via USB.

b) The POS machines are all connected back to the branch switch (let’s call it branch switch) and from there connects back to corporate HQ for reconciliation purposes

c) However – we found out that the Credit Card terminals have their own connectivity to their own ethernet switch (lets call it Credit Card switch) that connects to an ISDN router and directly to the bank.

This means, there are two flows – once the credit card is used on the Credit Card terminal, the card information is sent out directly via ISDN to the bank. Whatever approval etc that comes back, it will go through the USB to update the POS.

The crunch here is that NO CREDIT CARD information is ever sent back to the client’s environment. Everything is out through the bank environment – as the Credit Card Switch all belongs to the bank. It’s only located on the customer premise but the customer has no access to it – physical or logical.

So begin our argument with the acquirer, to overturn their SAQ D to SAQ B or B-IP. Let’s look at SAQ B criteria as per PCI document:

a) Your company uses only an imprint machine and/or uses only standalone, dial-out terminals (connected via a phone line to your processor) to take your customers’ payment card information;

Seems like it. Technically, the question here is whether a credit card terminal connected to a POS machine with USB is considered ‘standalone’. Our argument here is yes, as long as no credit card info flows through that USB connection and only approval/decline/transaction dollar amounts etc. Remember the USB connection connects the terminal to to the POS machine (a Windows box). Credit card info flows out the other way, directly to the bank via a circuit switched technology like ISDN (i.e dial out). For the millenials, ISDN used to be the granddaddy of broadband. If you have ever gone through internet connectivity era with normal dial up 14.4kbps, ISDN is like what God would send to us out of mercy and grace.

b) The standalone, dial-out terminals are not connected to any other systems within your environment;

Again, the argument here is ‘connected’. What does this mean? Is it through IP means, or even an RS232 connectivity is considered connected? Our reasoning is that this is USB connection and no card data flows through this ‘connection’ and we will use this reasoning once we get on the table with the acquirer.

c) The standalone, dial-out terminals are not connected to the Internet;

No they aren’t. They are on ISDN direct to the acquirer.

d) Your company does not transmit cardholder data over a network (either an internal network or the Internet);

No they don’t. In fact, no credit card info is stored, processed or transmitted anywhere in the customer environment. Except for the physical protection over the bank equipments residing on customer premise.

e) Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically; and

They do have some credit card info on paper which they need to protect, but these are manual forms they need to fill out for refund process. And the process is dictated by the bank.

f) Your company does not store cardholder data in electronic format.

No, of course not.

So you see, except for the tiny word ‘connected’ in question b), our client does meet all the SAQ B criteria. It’s really ridiculous to have someone go through the entire SAQ D when they do not have card holder data in the environment they control. And what if they have 80 branches, each with 10 POS terminals and servers? That would mean 800 systems in all branches come into scope for pentest, internal scans etc? No wonder I hear some retailers using PCI as a cuss word these days.

So, we don’t know how this is sorted out yet, but we will soon, and perhaps that will constitute another post. For now, if you need any help with your PCI-DSS – SAQ or Level 1 certification, drop us an email at pcidss@pkfmalaysia.com.

Cheers for now!

PCI-DSS Logging in MySQL Community Version with MariaDB Plugin

pci-compliance

PCI-DSS is a standard that brings to mind the famous sayings of Jimmy Dugan, the coach of an all-girls baseball team in the movie A League of their own (Played by Tom Hanks):

“It’s supposed to be hard. If it wasn’t hard, everyone would do it. The hard… is what makes it great.”

Well, at least the first part. Whether the banter of it making it ‘great’ is a different story. Most PCI-DSS sufferers will add the word ‘pain’ after the word ‘great’. And, one of the main pains for PCI-DSS is logging and monitoring. That’s requirement 10 for you. So much so that PCI-DSS recently released a document specifically addressing this issue here. So you will be faced with myriads of issues – from the simple to the hard: no we cannot centralise log anything, we do not have logging function in our application, we do not know how to do daily monitoring of our logs, we do not know what to log or how to log, we are all running on DEC VAX from 1974. So many reasons.

One of the challenge we recently faced with the client was that they were using MySQL community version. The challenge was how they can log administrator actions and security INSERTS, UPDATES etc in mysql community version? Logging is totally available in Enterprise, but not the free one – or at least not in its limited form.

Enter Maria-DB Plugin. Now before we go into semantics, MariaDB is an opensource database created by guys who created MySQL. It’s a fork, because MySQL was acquired by Oracle some time back and everyone was afraid that Larry Ellison might gobble MySQL up the way Galactus ate planets. The cutest story here is that MySQL was named after the founder’s daughter – My. And yes, MariaDB is named after his other daughter! But the first daughter’s name is “My”…so it’s like, “Yeah, this is My, My Daughter.”

Anyway. So what we are talking about here is not for them to install MariaDB, but to use it’s ‘plugin’ for MySQL. Make sure the QSA doesn’t get confused on this because ours did and we entered into the twilight zone of communications for a while where nothing made sense.

The Advantages of using MARIA DB AUDIT PLUGINS are:

So this article, we are going to explain on how we install the plugins in MySQL version 5.6.35 that is based on CentOS 7.

  1. Download the latest plugin from the links given above and you should see the download directory as below. Choose the latest version. We used server_audit-1.4.0.tar.gz. in centOS. We can use the wget command that is:
    wget https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/server_audit-1.4.0.tar.gz
  2. Extract the tar file by using the command
    tar -xvzf <file name>
  3.  Login into MySQL and locate the Plugin Directory of MY SQL using the command below
    SHOW GLOBAL VARIABLES LIKE 'plugin_dir';
  4. Copy the plugin to plugin directory in MySQL based on your linux server (64 bit/32 bit).
    • cp server_audit-1.4.0/linux-x86-64/server_audit.so /usr/lib64/mysql/plugin/
    • chown -R mysql.mysql /usr/lib64/mysql/plugin/server_audit.so

     

  5. Install the MariaDB Audit Plugin into the MySQL Server by this command inside MySQL
    • INSTALL PLUGIN ‘plugin name’ SONAME ‘filename.so’;
  6. Once Installation is complete, we’ll start the daemon with the following command in the command line:
    sudo systemctl start mariadb
  7. The command systemctl doesn’t display the outcome of all service management commands, so to be sure we succeed, we’ll use the following command:
    sudo systemctl status mariadb

    If MariaDB has successfully started, the output should contain “Active: active (running)”

  8. Next, let's take a moment to ensure that MariaDB starts at boot, using the systemctl enable command, which will create the necessary symlinks: sudo systemctl enable mariadb
  9. Next, we’ll turn our attention in configuring the syslog FormatSet the Type of Action that will be log (within MySQL)
  • Connect: connecting and disconnecting to/from the server will be added to the log. An unsuccessful connect will be logged as a failed connect including the error code.
  • Query: full statement including the values will be logged
  • Table: Any operation on a table triggered by query will result in an event the MariaDB Audit Plugin can catch to log it directly
SET GLOBAL server_audit_events='CONNECT, QUERY,TABLE';

You need to have root privilege to be able to change the Audit Plugin variables.  With this changed we are ready to enable the auditing, which we now will do by using the following command within MySQL:

SET GLOBAL server_audit_logging=ON;

The full set of variables is found on this page: https://mariadb.com/kb/en/mariadb/server_audit-system-variables/

To make the changes to the configuration of the MariaDB Audit Plugin permanent, we now need to add these settings to my.cnf. This ensures that the same configuration will be used after server restart.

Under [mysqld] in my.cnf, add in

server_audit_events=CONNECT, QUERY, TABLE
server_audit_logging=On

There you go, now your MySQL is ready to face the scrutiny of the QSAs in your PCI-DSS compliance program!

Email us at avantedge@pkfmalaysia.com for any enquiries regarding this plugin or PCI-DSS in general and we will get back to you as soon as we can.

« Older posts Newer posts »

© 2024 PKF AvantEdge

Up ↑