PKF AvantEdge

Category: IT Audit (Page 10 of 13)

IATA PCI-DSS: Who is doing what?

June 9, 2017 / / 0 Comments

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.

PCI-DSS and how we messed up the scope

June 4, 2017 / / 0 Comments

pci-compliance

Reflecting on challenges of a recent PCI-DSS project for a client and the key learning points for an effective implementation

People team challenges – having a team to champion the project

When we started the PCI project, we were faced with multiple changes in the client’s project manager and so the project was like a car unable to start on a cold morning (for those old enough to remember there were such cars back in the 80s!).

Eventually, by working with the client, the musical chairs stopped and we had a stable project team to champion the PCI-DSS project.

The importance of the scope

By then, so many changes had been made in the systems and people that we were asked to rescope the work.  Now, scope in any PCI-DSS project is absolute key. If you start wrongly, you will definitely go down the rabbit hole and never come out.

(Mis)Understanding the process flows

The client described how the credit card data was fed into their system through the credit card terminals connected to their POS systems in their nationwide store network.

Initially, we were quite surprised that credit card data would be flowing back into the retailer’s system so they could do their reconciliation.  Our experience suggested that retailers would simply transit credit card information through the credit card terminals to the acquiring bank and then receive back a transaction ID or approval code.

Further enquiries got the same answer and we were assured that the information would be ‘encrypted’ and stored in ‘encrypted’ form.

On the basis of their answers, the client expected to undergo an onerous Self-Assessment Questionnaire, consisting of over 320++ questions!

Managing information

Our team took their word for it, and began the project by asking them to draw out their process flows so we could assist them in scoping their systems and completing an asset inventory (a key part of the PCI-DSS programme) together.

And this was where things got a little messy.

Because they insisted the credit card terminals that were interacting with the cards belonged to the acquiring bank and they had no influence over it, they did not have an asset list.

Also, with a significant number of branches it was difficult to provide an asset list to cover all relevant hardware and software across the portfolio.

The pushback caused the project to once again grind to a halt. Without a scope confirmation, we could not start any PCI implementation for them, in case we over-committed or under-committed on the plan.

Benefits of documenting process flows

The project was being worked out at management level for a long time before it was brought up to the director level, but once it did, things began to move.

We decided to go on the ground to a few of the store locations to really see what was going on.

What we found out surprised everyone:

Credit card information indeed never flowed back into the client’s system!

Getting the terminology right

The so-called ‘encrypted’ credit card information from the bank that was supposedly sent back to the client after the authorization, was in fact, ‘truncated’, not ‘encrypted’.

Apparently, the client had thought these were the same thing.

In PCI speak, encrypt means to protect credit card details by making the information unreadable with a key. The main reason is that there is a need to ‘de-crypt’ the information back again.

Truncation, on the other hand, meant that the card number itself, when sent has already its numbers ‘X’ed out. This is different in a sense that truncated card information is NOT card information because the critical numbers have already been X’ed out, leaving (usually) just first six and last four numbers of the credit card number visible.

Immediately, it was like a light being flipped on.

The team worked hard to optimize the scope by confirming the other flows and observing live transactions take place.

At the end of a 2 day onsite scoping assessment, we concluded that this client was eligible for a much reduced – only around 80 questions – assessment and then by filtering further, we pared down their compliance questions to only 40 reducing the scale of this compliance project by more than 85%.

Key messages

The takeaway here, from our experience would be:

  1. All PCI-DSS assignments require a stable and strong project team – get the right people, in the right place, with the right focus
  2. Understand the client’s terminology and descriptions and then check and check again. Ensure that you start from the best position, and not chasing the wrong end of the stick.
  3. For PCI-DSS merchant compliance it is essential to explore if the client is eligible for any reduction in the scope and don’t just go with the default. The time and cost elements of getting this wrong could be very substantial.
  4. Nothing beats being onsite and to undertake live walkthroughs of the actual processes. In this case, the earlier the better, so the assignment can be properly scoped.  A different set of eyes might be able to unlock the project obstacle – and in our case, it was essential to have the onsite scoping exercise.

Finally, because of these findings, the compliance is now ongoing and finally we are seeing the light at the end of the tunnel.

If you have any queries on your scope or compliance on PCI-DSS, drop us an email at pcidss@pkfmalaysia.com and we will get back to you ASAP.

The SAQ Bs and how they apply to you

March 31, 2017 / / 0 Comments

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 and Multi Processing Environments

March 31, 2017 / / 0 Comments

PCI

Since our last post, we have received some queries from other companies asking us about their PCI compliance. Just to be clear, we do not charge a fee for replying to your email and assisting you make sense of this compliance. We know how frustrating it is, and no, anyone that tells you that PCI is easy as 1-2-3 isn’t really letting you know the full picture. This is because some emails had been – “I have this question, but wait, if you are going to respond and charge me a fee, then don’t bother.” What are we, mercenaries? Yes we are a company requiring profits and not an NGO, but over the 7 years we have been involved in PCI, we have actually done a fair bit of advisory without charge, just to get PCI awareness out there into the market.

So, to save the trouble, I’ll put up a public post here to sort some of the questions out. This question, we have been getting a fair bit: What if the company has a multiple processing environment? What does this mean?

Let’s say, a retailer. It has a POS environment whereby they run standalone terminals connecting to the bank for purchases in their store. Credit card is used here – card present transactions. Then they launch their e-commerce site, which redirects all card non-present transactions to a PCI certified payment gateway, where the card collection page is hosted by the gateway.

You see here – there are two different channels for credit card interaction. The traditional POS, and the e-commerce site. Both are completely outsourced – one is direct dial up to the bank, the other to the payment gateway. So how do you deal with this?

You have two options – one is to do separate SAQs for both environments. Yes, you can. In the example above, doing an SAQ B for your POS environment and an SAQ A for your ecommerce environment (assuming you are level 3 or 4 merchant) should be able to suffice. The second option is to combine these channels into one SAQ. Once you do that however, you won’t be able to go through the ‘specialised’ SAQs. Specialised SAQs are like A, A-EP, B, B-IP, C, C-VT – meaning they have conditions in which you need to adhere to in order to use them. For instance for A, it says that this will only apply to merchants with card non-present business. And likewise for B, it has condition that you do not store card information electronically and is not applicable to e-commerce merchants. So when you don’t fall into any of these SAQ buckets, you end up with SAQ D-MER, which basically covers everything in PCI. But don’t worry, you a lot of the SAQ would be non-applicable in this case, and only those related to outsourced e-commerce and POS facilities would apply.

Now another related question, and one that I ended up having a 2 hour discussion with a client on = can an entity be both merchant and service provider?

The short answer is yes, you can.

An example would be a telco. Telcos generally have massive merchant business. They accept payments for their pre-paid, post-paid etc from end customers through e-commerce, POS channels etc. But the Telco could also support a manage services and hosting environment whereby other merchants are hosting their payment sites on. Then, now you have a service provider environment.

Or, it could even be within the same organisation, you have your merchant business of a payment portal, Mobile POS, or mobile app, connecting to an outsourced payment gateway. Suddenly you decide you want to set up your own payment gateway and channel all the transactions of your merchant business to your own payment gateway.

In the first instance, if you have separate environments and businesses isolated from each other – you can again opt for separate compliance. You could be a Level 3 Merchant filling up an SAQ B form, and also a Level 1 Service Provider doing an ROC with a QSA.

In the second example where your merchant business connects to your own payment gateway, it’s a little more complicated because in all likelihood, the systems utilised by both business would be common. In this case, isolation and demarcation of type of business is more difficult to attain. Assuming you are eligible for Level 2 service provider, you can technically fill that up and ensure that it includes your payment channels within that SAQ. If you are doing a Level 1, then similarly, the QSA would likely include your payment channels (previously what you would call your merchant business) into your service provider certification efforts. Otherwise, you can still opt for a separate PCI compliance program, whereby you fulfill your merchant compliance, and for your service provider compliance program you do it separately.

For the latter option, the advantage is that if you launch your payment gateway and you provide options for other companies (not just your own) to connect to you, your compliance isn’t dependent on your payment channels (your merchant business). You would treat your own payment channels as just another merchant out of many, that are connecting to you. The downside of this is that you would likely need a clear demarcation and separation of systems between your merchant and service provider business.

Again, there are many ways to skin PCI. The best way (on paper at least) is to get your acquirer on the table or your payment service provider to ask them what is applicable to your business. Unfortunately, around 99% of the time in this region, the acquirers aren’t too knowledgeable themselves and either give wrong information or just tell our clients to do a Level 1 Certification with a QSA.

As part of our job scope – we will assess our client’s environment and provide the options on the table, and in some cases even be present on the table in the discussion with their acquirer – to obtain a clear indication on how to move forward and what PCI options are acceptable.

As always, drop us a note at pcidss@pkfmalaysia.com and we will do our best to accommodate your inquiries!

Passing PCI-DSS: Evidence Checklist – Brief History

January 29, 2017 / / 0 Comments

pci-compliance
We have been working on PCI-DSS since 2010. We started out as project managers for an offshore bank in Brunei that approached us asking for PCI-DSS compliance. At that point, we had invested a lot on training and getting our guys ISO27001 lead auditor certified because we saw a stable demand for compliance. We just banked on ISO and ISMS to kick off because of the directive of our government that all Critical National Information Infrastructure (CNII) needs to be ISMS certified. The reality though was slightly different. We pitched for jobs and saw precious few coming to us. Mostly, it went to agencies already incumbent, or agencies that knew how to get projects from government. We didn’t. We were new boys on the block and I remembered we were so desperate for business we drove all the way to Penang for a half hour meeting with a potential company only for them to say, Sorry we have already given the project away. Well, we did market that we had an office in Penang, so they probably thought we came to meet them from down the street. And not down the country.

In any case, in the middle of this desperate look for ISMS business, our customer in Brunei asked us for PCI-DSS. We didn’t really know anything about it, but we said, sure, let’s do it.

We called up some big QSA-Companies – Trustwave, Verizon being some of them. Verizon didn’t even bother responding to emails and calls. Trustwave did respond to my email – 5 months later. The only one that responded was a company called Control Case International. They called around 4 hours after I sent an email, and I was contacted not by their sales, but their founder, Kishor. He called me directly from the US and told me, let’s do this.

PCI is already a tough journey to begin with. We hear some QSA-C touting that it’s as simple as ABC. It’s not. And it’s not fair to say that it is because if it’s easy, everyone will be doing it. That’s not to say it’s impossible. With proper scoping, proper guidance, all companies can get certified with hopefully minimum fuss, stress and cost. Having local support and a responsive QSA is key. Local support doesn’t have to be a QSA. In fact, if possible, it might be even better to have non-QSAs and project specialists handling the local support. In our experience, QSAs are a busy lot and are often flying around on audits and working out other projects. Having a QSA handle your PCI initiative and remediation might not be the most efficient way as most meetings will be conducted either on a call or webex. PCI consultants are more than able to handle the remediation support because they are less caught up with ROC (Report on Compliance) writing and QA processes – which eat a significant amount of time for QSAs.

We successfully managed the Brunei project to certification and from there on, Control Case wanted to work with PKF for more Malaysian business. We started from zero clients to more than 30 plus clients today. Our goal is to push 50 by the end of this year. While we do work with Control Case, we remain independent as PKF does not have any influence over any report or opinion that Control Case has, and in almost all our projects, we work as project managers and technical advisors for our clients, not for Control Case.  In that way, we are not part of Control Case, or in any way represent or partner with them and even in some cases, we work with other QSAs to achieve the same results.

One of the key areas we work with the QSA and customer on is the evidence collection. Evidence is a key ingredient to your PCI success. We call it audit artefacts – proof that controls are in place. It might be a simple sample of change management tickets, or a more complex sample of 12 month logging of your database – in any case, these are the bedrock of your PCI journey. Without solid evidences that key controls are in place, passing the QSA’s Quality Assurance is going to be very difficult.

In the next few articles on PCI, we will share our evidence collection methodology, our 95 checklist of evidence and sampling on how to get these evidences sorted out for you to succeed in your PCI certification journey.

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑