PKF AvantEdge

Tag: compliance (Page 4 of 4)

IATA PCI-DSS: What Exactly is Required?

May 30, 2017 / / 2 Comments

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

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-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.

PCI-DSS Evidences: Your Type of Compliance

February 25, 2017 / / 0 Comments

pci-compliance

Since our last post, we have received some queries on how do we get PCI-DSS started. A majority of our clients are doing Level 1 Certification – this is where we come in and do a gap assessment, determine scope and then remediate and certify. However, lately we have been seeing more and more clients looking to do PCI-DSS on their own.

The question is: Can they?

Well – as with many questions for PCI-DSS, the answer is: it depends.

You see, the journey to PCI-DSS is different for different companies. Some need to go through the whole road. Some goes through just a little. Some need a third party to audit, some can do their own assessment…so while the standard is ONE, the ways to achieve it is MANY.

Now, enough of the philosophical babbling. Simply put: if you are doing PCI-DSS, you simply have 3 available options:

a) Third Party Certification

b) Validated Self Assessment Questionnaire (SAQ)

c) Self Signed Self Assessment Questionnaire (SAQ)

That’s it. You will fall into one of these buckets. If you fall under b) or c), you will then further have to wade through the types of SAQs: A, A-EP, B, B-IP, C, C-VT, D-SP, D-Mer, P2PE. Yes. They have a lot. But in general, your consultant or QSA should be able to tell you which one is right for your business.

Now back to the buckets. What’s a third party? No, it’s not literally a third party that you go to after your graduation and you are getting smashed. In audit terms, there are 3 kinds of audit – first party which is where internal auditors of the company audit themselves. Second Party which is where an external company with ties to the auditee company audits the auditee company – for whatever reason. It could be a supplier audit, it could be a due diligence audit before takeover, it could be a regulator auditing its regulatee etc. Finally a third party is a completely independent organisation auditing the company.

So the first bucket is a third party certification. This is where an external company called a Qualified Security Assessor (QSA) assesses your company and provide a Report on Compliance. This is where they will ask you to do a gap assessment, assist you through the ‘remediation’ period, and do the certification. What a lot of people don’t know is that actually, Merchant Level 1 also has an option to do a first party audit. This means they need an ISA (Internal Security Assessor) in their organisation who is able to sign off on the ROC. Of course, getting an ISA certified is another story, and in most cases, many just take the QSA route.

The second bucket is a Validated SAQ. This will not apply to Level 1 Merchants or Level 1 Service providers, and this is available for Service Providers Level 2 or Merchants Level 2 and below. Basically this means that theoretically, you can complete the SAQ that is applicable to your company and sign off and you are ‘compliant’. This also means any Tom, Dick and Harry who thinks that a firewall constitute setting an actual office wall on fire, can sign off on 1.1.4 (a) which asks if a firewall is implemented in your company. Seriously though. That’s why Mastercard has this caveat:

“Effective 30 June 2012, Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

Many, including myself, find this caveat extremely frustrating. To cut the long story short, Mastercard is simply saying for all Level 2 merchants you have 2 routes:

a) Do the Level 1 route. Get a QSA

b) Do your SAQ, but get the staff ‘engaged in the self assessment’ to be ISA certified. Now the first confusion is staff engaged in self assessment does not mean everyone involved in the audit. It basically means the one doing the assessment in behalf of the organisation and signing off at the AoC (Attestation of Compliance) of the SAQ. Whew! But still, now you need to get an ISA. It’s not cheap! And it’s also, to me, a really silly certification, but one that makes total Sen$e to the PCI-SSC.

In theory, option b) above is correctly still called ‘Self Assessment’ as it is still a first party audit in that sense.

Now the last bucket therefore is the truest first party audit. This usually applies to only Level 3 or Level 4 merchant, but sometimes we still find this existing in Level 2 Service Provider. Where the management say, “Screw it, let me sign it off and I don’t need any other signature on this” and the bank, customer or card scheme accepts it.

So this is the first step of your compliance – find out your type. Because you could be overdoing it (Level 3 Merchant doing a ROC Certification) or you could be underdoing it (Level 1 Service Provider doing an SAQ D). If you overdo it, it’s fine from PCI-SSC perspective, but your boss/stakeholders/board/customers might not be too happy when you have spent half the company’s budget and 8 months on the PCI program doing a full Level 1 RoC on all the 340++ subrequirements – and the vacation trainee points out that you only have to do a self signed SAQ A which takes about 1 day to complete. If you under-do it, likewise, you might be in an awkward position to explain to someone that your SAQ D-SP is not enough to convince your acquirer to start connecting to them, as they need a QSA signed ROC.

So how do we know?

Well – the easiest is to really, ask the ones who are pushing you for PCI? If you get the answer : “Ah, just get compliant!”, then you have more leeway to understand your business, and you might be tempted to just go for the easy way out. Don’t! Assess your business – if you are a merchant, then follow the number of transactions to determine which level you are at. Easy remembering:= 6 million and above for level 1, 1 – 6 million for level 2 and the rest level 3 and 4. I don’t differentiate 3 and 4 because there doesn’t seem to be a squat a difference to what you are supposed to do. It’s the same, they just classify it differently where level 3 is focused on e-commerce and level 4 is more on traditional transactions.

For service provider, it’s simpler. Level 1 is above 300,000 volume of card transactions and level 2 is below. There is no other levels for Service Providers. There is also only SAQ D available for Service Providers so you don’t need to think so much.

The next round, we will explore deeper into how do we get our scoping questions sorted out.

 

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.

Newer posts »

© 2024 PKF AvantEdge

— Up ↑