PKF AvantEdge

Tag: PCI-DSS Malaysia

PCI-DSS Cheatsheet

December 11, 2019 / / 0 Comments

As we approach the end of the decade, we are approaching 16 years since PCI-DSS was first introduced back in 2004. 16 years. That’s probably a full dog lifetime. I would imagine the guys back in 2004 would have thought: “Let’s just get version 1 out this year. I’m sure our next generation of brilliant minds will figure everything out by 2020.”

So now we are a few ticking days away from 2020 and yet, at the end of the line, I am still answering calls that are increasing as the days go by: What is PCI-DSS and how do we get it?

Most of these callers are generally calling because our names are listed pretty high on the internet when someone types in PCI-DSS Malaysia. Apart from that, a majority of these callers are calling because we were reference by one of our clients. We have faced different variations of callers coming in: Some requests us to provide them with a PCI-DSS ‘license’ in order to operate for their clients. Some requires a ‘certificate’, some are literally clueless as to what it is but their banks have mercilessly dumped this whole requirement to them.

Step 1: Who’s Asking?

First of all, take a deep breath, here is a simple cheatsheet. Whoever is asking you to be PCI-DSS, take note of it. Here are the Usual Suspects:

Bank – Very likely you are connecting to them doing some sort of payment processing like a payment facilitator, a TPA etc. Or you could be a service provider and your client just happens to be a bank, which brings us to

Customer – your customer for some reason is dealing with credit/debit cards, either directly or indirectly, and they require you to do PCI-DSS because you are servicing them or they have outsourced to you, like BPO, Data Center, hosting, call center, or even network transit

Internal – One of your internal managers have read up about PCI-DSS and decided that your company will sound very cool if you are PCI-DSS certified. Now, in this case, you could or could not be PCI. Because PCI is a contractual obligation dealing with credit/debit cards badged with Visa, Amex, Mastercard, JCB, Diners/Discover – if you don’t deal with this or have any clients dealing with it but your company just wants to get any standard out there – my suggestion wold be to go for something like ISMS (ISO27001) as that’s a better guideline rather than a contractual standard like PCI-DSS. If you still insist – well, you could still go through the SAQ but a lot of it will be not applicable to you since you are Non-CDE for everything.

Those 3 are mainly the motivations behind PCI-DSS. Why is it important to determine who is asking, is because of the next step:

Step 2: Determine your Level

Now there are guidelines out there for which level you should be at. If a service provider, then anything over 300,000 volume of card processing will bump you into level 1. For merchant, anything over 6 million for level 1 and anything over 1 million for level 2. I can’t count the times people get mixed up with Service provider levels and merchant levels. Even banks. I have banks telling our payment gateway that they are Level 4 . There is no such thing. It’s either one or 2. For merchants there are level 1,2,3 and 4 but the volumes are different.

Now while the guidance is cool and all, at the end it’s your bank or customer determining your level. If your bank decides to only deal with you if you do a full certification and RoC with a QSA, then even if you are processing ZERO transactions, they have deemed you as level 1. You can then decide to either say OK, fine, or tell them you are taking your business elsewhere. In that case, they may decide not to play hardball. I don’t know. Same as your customer. Your customer may decide you need to be assessed by a QSA, so it’s best you determine this with whoever is asking you.

The secret sauce is this: Most of the time, your bank/customer won’t have a clue what they want. They will just say, Oh, be PCI compliant. In this case, approach them with some tact. Your mission, should you choose to accept it, should be to avoid level 1 certification as much as you can, if your volume is low. It’s not justifiable. Look, if you want to be assessed by a QSA, by all means, but at least, know that you have a choice if your volume is low, and your bank/customer isn’t fussy about it. Just tell them: “OK, I’ll be PCI-DSS compliant, and I will fill up the Self Assessment Questionnaire (SAQ) and our management will sign it off and send it over to you. Is this OK?” If yes, then great, do your own self assessment. You can save up some money.

Step 3: Determine your Controls

This is probably the trickiest part of PCI-DSS. You see, being level 1 or level 2, self assessed or third party assessed, SAQ or RoC does NOT make any difference on what controls you need to have in place. An example: Level 1 compliance may require you to do ASV scans for 3 external IPs and 20 Internal IP Penetration testing. Guess what? Even if you are doing an internal self signed SAQ, you are supposed to do the SAME THING. No difference. No “Oh, since I am level 2, I will do ASV scans for 1 IP and maybe take 5 Internal IP for Pentest instead of 20.” In theory, all controls are the same, the only difference is WHO assesses and attests these controls.

Now, of course, realistically, this is not happening. Like I always illustrate, some companies consider a firewall as a wall on fire and they sign themselves off as PCI-DSS. Hence the whole passing the buck, passing the risk thing about PCI that I won’t go into discussion here. But in theory at least, same controls apply. But how do you determine what applies to your business? Well, based on your business flows of course.

Determine above all whether you are storing credit card information. If you are not, roughly 35% of PCI-DSS is not applicable (I am plucking that % out of no where, so don’t quote me). But a big chunk isn’t applicable. Second, determine whether you even interact with credit card or not. Look into all your channels. It could be complex like a call center, or simple like a network transit. In most case if you can determine that you have no access to credit card PAN or don’t store, and don’t process, the controls that are applicable to you are minimal. You should STILL be PCI compliant, but minimal controls apply.

Step 4: Determine your vendors and outsourcers

We had a client who cancelled an ongoing PCI-DSS with us because they have deemed themselves PCI-DSS compliant because they are using a PCI-DSS software. I cannot count the number of times I have to correct them – NO. Just by using a software which is PA-DSS compliant or even PCI compliance (like Cloud) DOES NOT make you PCI-DSS compliant. Will it help? Sure it will, but can you piggy back on someone else’s compliance? No. You can’t. So either you go through PCI yourself, or stay non-compliant, but don’t say you are compliant when you are only using a software that is compliant. That’s like saying you are certified to fly a plane when you are a passenger of a plane flown by a certified pilot. Or something similar.

Get your vendors on board for PCI if possible. If they refuse you can still use them, but you now have to include their processes under YOUR PCI-DSS program. Why would you want to spend extra days getting your vendor compliant when there are OTHER vendors who already are compliant?

So there you have it:- When someone requests PCI compliant – first, review your options. There is no ONE way for PCI. Go with the least resistance – self signed SAQ if your volume allows it. That saves you a lot of time and money as opposed to getting a QSA to come in.

If you have any queries on PCI-DSS, drop us a note at pcidss@pkfmalaysia.com and we will attend to it right away! Merry Christmas!

IATA and PCI-DSS to Travel Agents: Data Channels

April 30, 2017 / / 0 Comments

PCI

IATA has for a few years been championing the need for PCI-DSS to the travel agencies that are registered under them. More recently, they have been pushing compliance for PCI and even made a deadline at June 2017 for all agencies to be PCI compliant. Unsurprisingly like many well intentioned deadlines, it is now pushed further back to March 2018. Our prediction is that by November or December this year, we might see yet another delay in the deadline. But that doesn’t mean there’s any let up in compliance. Therefore, we’ve been reaching out to many of the agencies who were our clients previously and letting them know if they need help on their SAQ, they know where to find it. Us!

Now, just to summarise, being registered with IATA means a big deal to an agency. It simply means you can issue tickets. So how it works is that IATA is like a national ‘switch’. Whereby registered members can receive calls from clients, and based on pricing etc, select the airline and pricing and issue these tickets – either to other clients or in behalf of even other agencies. Firstly, there is credit card involved, of course. Secondly, IATA members can tap into the BSP – the IATA Billing and Settlement Plan. This is like a huge payment switch – whereby it handles all the payments to multiple airlines from the agencies, so that agencies don’t have to deal individually with airlines for settlement of the tickets. Which is good. Secondly – there is the GDS (the global distribution system). There are a few players in the market – Sabre is one of the biggest (used by Malaysian Airlines), others are like Amadeus, Patheo etc. We’ve so far encountered Sabre and Amadeus in our clients and both of these are PCI certified providers.

So, with this basic understanding of how agencies work, how does PCI apply?

First of all, unless IATA makes a statement otherwise, agencies DO NOT NEED a QSA to do a level 1 certification or sign off on SAQ, unless explicitly requested do. Since IATA is the processor for the agencies in this case, it’s their call. But it’s a big call, because level 4 merchants aren’t very large and they might not be able to get QSAs to help sign off their documents. We are working with one of the largest merchants at the moment and even they are not requested by their acquirer to get a sign off on SAQ from a QSA.

99.99% of agencies out there will fall under the Level 3 or Level 4 merchant band and we all know what that entails – SAQ, signed off by their executive – only if required should they get a QSA to participate. But it helps to have someone that knows about PCI or else you would be groping in the dark with the SAQ options.

What we see a lot are merchants automatically selecting SAQ D-MER when it comes to PCI. Again you don’t have to.  Depending on the number of channels you have you might be able to select C-VT, or B, or even A-EP, A. We call these specialised SAQs – remember, if you don’t meet any of these criteria, you drop into the SAQ D bucket.

What many people don’t know is that you can opt for a separate SAQ for each channel, instead of having one SAQ D to cover all. Both are possible, but its just that for SAQ D, you would be marking a fair bit N/A if you are say just doing POS and e-commerce.

Before we venture into the dark arts of SAQ selection, let’s explore probable channels that agencies have.

a) Through the website – this is not that common actually. Now with Expedia, Agoda and all these portals coming up, it’s easier for consumers to get the best price regardless. But for corporate trips etc, some of these websites might still prove useful. Most of these websites will either redirect to another payment gateway or might even link to a GDS. Either way, they generally do not host the site where credit card information is being entered. So in this case, SAQ A might work. If they have card information collected in their environment before sending it over to the payment gateway, then SAQ A-EP. Questions for A = 22, A-EP = 191. So please think it over as to why you want to collect card information on your site.

b) MOTO – or Mail Order Telephone Order. In most cases, there would be a call into the agency requesting booking. Now it’s important then how card data is now transmitted, processed and stored. The agent likely will not have any funky call system like Ameyo or Genesys, and may just rely on our good old PSTN phone line. Once call is received, the agent will request details , including card details and type it directly into a GDS system. In this case, as there is no recording on the line, it’s fine, and as long as the agent is using a hardened desktop/laptop with a virtual terminal into the GDS, you can rely on SAQ C-VT to cover this. Now, what is a virtual terminal? Basically, it’s a virtual POS. You just don’t need to buy the POS devices. All GDS offers this solution, whereby you log into the virtual terminal and just input the card information.

The tricky part here is that not all information is received on phone. Sometimes, clients will say, OK, let me send you a batch of credit card info in a text file via email. Or, hold on, I am shooting you an image via WhatsApp or Skype. Or, wait, let me fax you the form. Oops.

Now what happens is that other channels are being utilised. You have storage of credit card information. You are no longer eligible for C-VT. C-VT = 81 questions. D-Mer = 332 questions. So, if you can stop these practices, I would suggest, go ahead and stop it.

c) Walk-In – most agencies have outlet(s) and you can walk in, and pay off the counter. They will either key in the information as if you had called, into the virtual terminal – OR, they might have an actual POS machine for you so you can dip your card and make a card present transaction. In this case, it depends on how the POS machine is setup. It would be pretty similar then to a normal retailer transaction – like a grocery store or departmental store. We’ve already written this at length here: http://www.pkfavantedge.com/it-audit/the-saq-bs-and-how-they-apply-to-you/.

So there you have it. Remember the following

SAQ A = 22 questions (good!)

SAQ A-EP = 191 questions (not great!)

SAQ B = 41 questions (good!)

SAQ B-IP = 82 questions (not so great!)

SAQ C = 160 (not very good!)

SAQ C-VT = 81 (that’s ok!)

SAQ D- MER(SP) = 332 or 359 questions (bye bye weekends!)

So there you have it. If you are an agency or a retailer and you need any help at all to clarify this PCI-DSS requirement, drop us an email at pcidss@pkfmalaysia.com. We will attend to you immediately!

 

 

PCI-DSS Logging in MySQL Community Version with MariaDB Plugin

March 18, 2017 / / 0 Comments

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.

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.

PCI-DSS Landscape in Malaysia

August 21, 2015 / / 0 Comments

pci-compliance

2014; this was the year where PCI DSS really took off for many companies and organisations in Malaysia. More and more banks have pushed their merchants to be compliant and certified with PCI DSS.  While a few merchants require Level 1 certification or Level 2 validation, a bulk of them will fall under Level 3 and Level 4 Merchants. That means a lot of ASV scans, and a lot of Self-Assessment Questionnaire (SAQ) Advisory. I was asked this question: why are these banks, who are traditionally so dormant and make corporate decisions slower than a crippled sloth, half blind and halfway to the grave, now have suddenly become so actively engaged in PCI DSS? Perhaps this is due to the pressure they get from the card brands – especially VISA and MasterCard.

After what happened to the infamous Target retailer during the 2013 – 2014 and other high profile hacks, card brands are now in caution mode and have become more stringent to entities connecting to them. This, in line with the new PCI-DSS V3.1 means that controls are more stringent and auditees are more frustrated. Like everything in PCI – it’s a top down domino effect – VISA insists on banks being certified – banks claim that they cannot be certified but they are in the process, and they in turn insist their third party processors or merchants be compliant. I call this ‘passing the buck’ philosophy. It’s an open secret that no banks in Malaysia are certified. They will claim they are compliant, the same way my 25 year old refrigerator is compliant to green and environmental friendly regulations. It’s not.

Because banks push this compliance downstream, this “passing the buck” effect has caused many entities to start actively looking in every direction to be certified or compliant because they don’t want to lose connection with the bank. Is it fair? As one of our merchant client bluntly puts it: “It’s like being blamed by tobacco companies for polluting the planet with our smoking.” While drawing in a long drag on his Marlboro Lights and looking wistfully into space.

Should banks be certified? Of course.

However, for them to get certified in a specified period of time is difficult due to their ever changing business nature and an overly large scope of systems, people and processes under PCI requirements. Therefore they will need more time to remediate all the gaps and guess what – one of gaps would invariably be getting their third parties (like my client with his Marlboro Lights) certified.

At the end, the service providers and merchants and payment gateways are forced to be more aware that PCI is needed for them to ensure the continuity of their business especially if it involves VISA and MasterCard. So why aren’t they getting certified?

The answer lies in the implementation cost. Smaller to medium merchants, emerging payment gateways who have limited funds, limited clients – they might consider that the cost of them to pay for any breach is lower compared to certification. For example the need for an IDS/IPS (Intrusion Detection/Prevention System), the need for a system logging server, the need to perform daily log review and review reports.  All of these require either additional effort or cost in terms of time, human resource or investment to acquire new devices.

With problems, there will always be solutions. We are keenly aware not all clients can afford the expensive solutions such as having separate devices for IDS, FIM (File Integrity Monitoring), syslog and etc. Or to build a Security Operation Center ground up. We have crafted out different solutions to serve our customer’s needs, from providing an all in one system for compliance to even having them outsource their compliance headache to us. Yes, we love to transfer headaches from clients to ourselves. We call our solution PCI Panadol. Just kidding, but it’s a great name.

Our solution starts with this question: How do we get you compliant with the least effort, least time and least money possible – and to maintain compliance with these 3 LEASTS (effort, time, money)?

Overall, awareness of PCI DSS has grown a lot in Malaysia. PKF Avant Edge does monthly PCI Awareness training (HRDF Claimable) and we have served large clients through such training.  As for implementation, it is just as important to know what is UNNECESSARY for PCI than what is necessary. It starts with the scope. Start right, and you might just cross the other side of certification and celebrate with a party. Start wrong, and you are looking at a very, very, very long journey with very little happiness in it.

For PCI scoping or advisory on how we can help you in your PCI-DSS journey, drop us an email at avantedge@pkfmalaysia.com or contact us at +603 6203 1888.

by Wafiy Karim, PCI Consultant.

© 2024 PKF AvantEdge

— Up ↑