PKF AvantEdge

Tag: pci malaysia (Page 3 of 4)

PCI-DSS: Internal Audit Signoffs

April 17, 2019 / / 0 Comments

After going through previously the nightmare of PCI-DSS Certificates, as described with considerable detail in our writeup previously, we are now faced with a new phenomenon called the Internal Audit Signoff, which is further confusing our clients.

OK, first of all, let’s do a brief recap.

How are 3 ways that PCI-DSS can be validated?

Answer :

  1. Full Report of Compliance (RoC) from QSA – Level 1 Service Providers, Level 1 Merchants
  2. Self Assessment Questionnaire (SAQ) signed off by QSA/ISA – Level 2 Merchants, (Maybe) Level 2 Service Providers
  3. Self Assessment Questionnaire (SAQ) signed off only by Merchant/Service provider – Level 3,4 Merchant, (Maybe) Level 2 Service providers

Those are the 3 endgames for PCI. And of course, the end scenario called Failure, or non-Compliance. But that isn’t cool, unless you are the type who is happy with Thanos snapping his fingers being the definite end to all things.

Now we all know item 1) requires the participation of a third party QSA/ISA to signoff on the Report of Compliance and the Attestation of Compliance. ISA here is internal security auditor. We won’t touch it this round, because this requires a whole new library of articles to discuss.

Item 2) likewise requires a third party QSA/ISA to signoff on the Self Assessment Questionnaire and the Attestation of Compliance.

Item 3) is basically, self signed – not a lot of acquirers take this seriously as basically, its anyone signing off anything they feel like. There is no validation, and sometimes, it’s akin to the CxO sticking a finger to the tongue and putting it up in the air and going, “Yeah, that feels ’bout right. Let’s sign off and say we have these controls!”

Let’s talk about item 1 and item 2.

In item 1, it’s a gimme that the QSA needs to go onsite to the locations to do an audit. I have never heard of any QSA signing off on a full RoC without actually going onsite. Maybe when our tech reaches a point where the QSA can be holographically present in a location and see what’s there without being physically there like a Jedi Force Ghost, that the PCI-SSC would accept the signoff. But by then, we could probably just tell PCI-SSC that these aren’t the companies they are looking for, and then there’s no need to do PCI.

Until then – the question is for item 2, for the QSA to signoff the SAQ, must they be onsite or they can provide a remote signoff?

Now if you ask a QSA what is the difference between 1) and 2), they would say, not much – except they don’t have to waste their time writing the tome called the Report of Compliance (ROC) for level 2. Level 2 is basically a judgement made by the QSA based on existing evidences that what is stated in the SAQ is true, or at least as much as they can have reasonable assurance on. The SAQ is not a document written by the QSA, although they can help, but in this case they are validating it. For Level 1, it’s a different story. They have to write the RoC and the work put into that reporting phase is surprisingly a lot. In comparison, it’s probably like reviewing a first term essay paper written by your senior students (SAQ Validation) versus writing the Silmarillion including the index (RoC).

However, for QSAs to conduct their audit and provide a fair opinion on the controls, they will still want to be onsite for option 2), much to the chagrin of many of my customers. Their argument here is: “Hey I am level 2, why must you come onsite??” And again, the crescendo grows that a Level 2 should have less things to worry about than Level 1 – another myth as old as us telling our children not to sleep with wet hair or else they will wake up with a storming headache.

To get to the bottom of this, we got directly from the horse’s mouth (in this case from Mastercard SDP program response: “In this scenario (describing item 2) the QSA has to be onsite. The QSA cannot simply review a RoC or SAQ without being at the location to validate that controls are actually in place.”

To be fair, the above discussion was applied to L2 Merchants (Level 2 Merchants) – those making more than 1 million volume card transactions per annum. Whether the QSA is willing to take the risk and perform an offsite review for a Level 3 or level 4, I wouldn’t know – that’s up to the QSA and the card brands I suppose. But to be absolutely safe, we would advice that all levels should be treated as such – if you need a QSA to signoff, that QSA needs to be onsite to get it done. Or use the Jedi Force Ghost. Both are acceptable to PCI-SSC I am pretty sure.

So, as an illustration, we had a request from a company, requesting us, for their location, to get the QSA to signoff remotely. Because “The Other QSA did it for us and certified us”. The other QSA meaning someone they engaged earlier.

OK – this certification term again. I am sure that did not happen – but many use the word certification for anything: actual RoC, doing the SAQ with QSA, signoff on SAQ by themselves, getting ASV scan etc…those are typical scenarios we see this certification word being thrown.

Digging further, we received a worksheet which was a typical ‘Scope’ document (you know, where they ask what sort of merchant you are, what business, how many locations, devices, whether you store card etc), and the instruction was to fill this up, send it over to the QSA and the QSA will ‘sign off’ their PCI-DSS compliance, all within 2 weeks.

QSA certified within 2 weeks, remotely, and with just the scope document, without validating any controls? No penetration testing or ASV? No Risk assessment? No review of information security policy? How?

We asked for the copy of the official signoff page (Section 3c of the AoC) but instead we got a signoff on a report from QSA stating what was scoped in and what was scoped out of PCI-DSS. A typical scope document. It’s a useful document, but it’s not a document required by the PCI SSC. In fact it doesn’t serve any purpose other than to simply state what is in scope for PCI-DSS based on the scope questionnaire (not the SAQ) provided by the QSA.

I am 100% sure the QSA meant well by this, but the problem was, there are interpretation issues. We cannot expect clients to right off the bat understand PCI-DSS and all it’s seemingly malarkey documents – the AoC, the RoC, the 9 different SAQs, the ASV scans, the partridge in the pear tree etc. So when we asked for a SAQ signed off by QSA, of course, clients will fall back to any document being signed off by QSAs. That’s why we are not big fans of the practice where clients are provided by ASV certificates just because they passed their ASV scans. They all think they are PCI certified because they have a QSA signed off document which is the ASV ‘certificate’! And the same here goes, this is simply a scope review document – almost like an internal audit report, that does not make a company PCI compliant. In fact, it is just confirming that the company MUST be PCI compliant according to the scope set.

So the moral of this story is: Not all QSA-signed off documents are valid documents for PCI-DSS. ASV scans, while valid, doesn’t make you PCI compliant. It’s only a small percentage of what you must do. Internal Audits or scope reviews like the one we saw, even signed off by the QSA, are not valid PCI-DSS documents. They do not make you PCI compliant. As PCI has explicitly stated before, the only valid PCI-SSC documentation are the AoC, SAQ, RoC and ASV scan reports (not certificates, with flowery borders and impressive cursive fonts in gold). Anything else are supplementary materials used to support the compliance, not to validate it.

For more clarity on PCI, drop us an email at pcidss@pkfmalaysia.com. We will try to sort any issues you have, and yes, we are the company you are looking for.

PCI-DSS: Business Not As Usual

June 21, 2018 / / 0 Comments

Have you heard the phrase Too Long, Didn’t Read? What if this applies to your PCI DSS compliance program, rephrased to “Too administrative, didn’t’ do?”.

We get this all the time in our meetings. Everyone mobilise for the big PCI project, everyone celebrates when they get certified and everyone suddenly gets collective amnesia and forgets about it. They forget there are daily requirements (like daily review of logs), weekly requirements (like FIM file comparisons), monthly (like critical patching), quarterly (ASV etc), half yearly (firewall reviews etc) and annual (testing etc). Yes, there are such requirements. We generally encourage our client to celebrate their success for first time certification but keeping in mind these obligations. Certain things you just can’t afford to miss out like your ASV scans and Internal VA scans.

PCI calls this Business As Usual (BAU). Being so long on the receiving end of these compliance requirements and now dishing it out in our advisory, I can safely say: PCI isn’t business as usual. In theory, yes, it should be, but theory and reality remains as far away as the possibility of Malaysia winning the next World Cup. A lot of our clients, after winning the PCI certification, find themselves completely overwhelmed with the so called Business As Usual theory that they wonder, whether after achieving PCI Business As Usual whether there will be any Business left to be usual about.

So what happens now that you are PCI compliant? When you are planning your PCI DSS compliance maintenance, you may want to setup a team to look into all the requirements, be it the technology, process and people. After you get your PCI DSS compliance, remember, the ‘maintenance’ clock starts. Yes. So if you take 2 months to celebrate your victory over this dastardly villain called PCI, you technically have one month left to do your Internal Scans and ASV scans. So don’t forget about what you need to do. Your PCI team needn’t be dedicated personnel (Very few companies can afford that), but there should be a lead person, relatively not bogged down by day to day operation works, and ideally independent from the operations as well. If you have a info sec team, it would be good, else a technical project manager to lead and the responsibilities to maintain, to go back to the process or system owners.

True, even before PCI arrives, you are probably already bogged down by other compliance requirements on top of your normal day to day. ISMS, customer audits, regulatory audits and assessments, internal audit, and now PCI. It’s like eating pancakes after pancakes except these are horrible tasting pancakes.  You might forget some of the administrative tasks that need to be maintained as part of your PCI DSS compliance process and we have had customers scrambling to complete their quarterly scans after missing them. Eventually, after a period of time, all these tasks will pile up on your plate and you are left with the prospect of being unable to be recertified. Your PCI DSS compliance will be at risk of becoming non-compliant and void and really, it’s not something the board will be too happy about, after taking 3 months of budget to celebrate the victory earlier. It’s like winning the English Premier League one season and getting relegated the next. The emotions are too much. We may think these maintenance tasks are petty but it is an important component in your PCI DSS compliance ecosystem.

Here are some insights to some examples of these administrative tasks that might be missed:

Changes on firewall/switch/router rules or configuration– it is highly critical that before a change is done, proper testing, approval and documentation are carried out. As these devices are critical components in the network infrastructure, any misconfiguration may result in security issues or in our observation, even bring down the whole network and have people scrambling over the weekend unnecessarily. Proper testing and approval process are any case required before changes can be made and this must be documented. Documentation provides an audit trail of changes and why these changes are required. So, don’t forget to document this process. Or risk the weekend being messed up.

Patching – There is this perception that if I’ve setup my systems to perform patching automatically, everything is well. Wrong! You need to review the patches and ensure that it is safe to be deployed and it will not like, I don’t know – crash your production systems? Next is to make sure the patching applied is being documented so that you have a history of updates on your system. A configuration information (CI) system can do that, or you can ensure you run your inventory checks regularly, as Windows would keep track of these applied patches. If the system is being patched up manually, you need to have the procedure of checking for updates on a regular basis. Make it a habit to check if your system is running with the latest patches regardless if the patching is automatic or manual by making it as a checking activity in your periodic task list. Remember, PCI would require a one month critical patch deadline and three months for non critical security patches.

Anti-malware – anti-malware will normally update automatically and periodically and we will assume that it will run as what it is being configured to do. As such we will not bother to check unless something bad occurs (which almost always does). As part of your administrative task, you should make it as a daily task to check the anti-malware system status, malware detected and the resolution of it and put this task in your checklist.

Logging and Monitoring – PCI DSS requirement 10.6.1 requires review of security events at least on daily basis. Most people stare blankly at me as if I’ve just told them elephants do wear tutus and can fly. Then they realise that I am not joking, they shake their head and invariably say (in variable tones, depending on how incredulous or stupefied they are): “WHAT?! DAILY?!?” .

Well, yes, in a way, although PCI in its supplementary document Effective-Daily-Log-Monitoring-Guidance.pdf, they have provided this little leeway for your ease:

“A reasonable timeline must be defined to allow less capable organizations to perform security log reviews while still enabling the organization to detect malicious or anomalous activity before it can likely escalate. In the case of Requirement 10.6.1, PCI DSS has determined that timeline to be a maximum of 24 hours or one calendar day.”

So when we refer to ‘daily”, it is with this definition in mind. Still a difficult one, but hey, OK.  In our advisory works, we have seen that clients often miss out the daily review and alert they receive (usually through email). It could be a SIEM (Security Information and Event Monitoring) system is deployed and configured to identify a threat and sends out an email to the person in charge. Instead of monitoring this email that might be a critical security issue, it is not reviewed. Not reviewing security alerts is a risk that may have adverse effect for obvious reason. In a recent retailer breach, for many months hackers were siphoning information from their POS systems to a spool server and removing that data file to an external system. If reviewed properly, such an abnormal data flow might have been spotted.

So, these are a few of the admin tasks. There are a lot more. Moving forward, be diligent, make it a habit to not miss any of these out and incorporate these administrative tasks as part of your daily routine tasks. Other tasks include ensuring quarterly testing such as ASV, annual penetration testing, etc as described in requirement 11 are carried out properly and given enough time to perform. Don’t expect your team or vendor to do a pentest on 50 systems and tell them to complete it by tomorrow. Failure to observe PCI timelines may result in you losing your compliance.

Don’t get relegated after winning the league!

Contact us at pcidss@pkfmalaysia.com for further queries on PCI-DSS and we will set up a meeting with you as soon as you are available.

PCI-DSS: The Art of Getting By

April 6, 2018 / / 0 Comments

The Art of Getting By is a movie that wasn’t very good. I don’t recall much of it, except the title was appropriate for this article.

The general idea of PCI-DSS is that it’s easier to maintain the compliance than to first obtain it, and while there are nuggets of truth there, we would venture to turn that idea upside down: It’s much harder maintaining it that to obtain it. Maybe it’s like marriage, where after the wedding and honeymoon, the real work begins in ensuring you have 40-50 years left in the tank with your partner (depending on when you tie the knot of course, and in some cases, depending on how many kids you end up having. That’s added stress.). In some ways, it’s similar, and over 8 years of PCI experience had taught us that while we should always (again – ALWAYS) celebrate the success of first time compliance to PCI, we must not forget what lies ahead of us.

PCI Council realises this and in Appendix A3 of their PCI standard, lists out a few extra things for DESV (Designated Entities Supplemental Validation). It must be noted however, these are not automatically mandatory for PCI companies, but for companies designated by their card brands or acquirer based on risks and oftentimes, volume of transactions. If you are not required to go through DESV, don’t go searching for it.

DESV puts in a few extra components to the PCI standard. One of the requirements is to Implement a continuous PCI-DSS program in the organisation. What has been noted by the council is that while many companies do attain PCI-DSS, they treat the standard as an event they need to get by each year. This means companies, instead of practicing PCI in their daily work, seek to re-certify each year based on a series of checklist they need to do at that point in time. Which isn’t cool. But that’s how almost everyone approaches it. It’s like taking your semester exams in University. It’s not like in day to day living, we are thinking about the real value of x in a log2 equation or what are the prime numbers that are relevant to your life. We are just thinking about hanging out, cutting classes and kicking up dust. When the exams come, we mug, we eat ramen noodles for every single meal, we don’t go out, we don’t sleep and we generally try our darnest not to fail, and then the whole cycle of meaninglessness begins again. I don’t really recall much of my university days, as you can tell. And that’s how PCI is sometimes approached.

So how does one stay compliant, instead of just pass compliance?

Management Buy In

We hear this a lot from our management text books. Management Buy In. Unless we have a top down support and sponsor on compliance, PCI is going to be a drudgery faced every year. IT is going to be bombarded with all kinds of requests on top of their already busy day to day work. Most success comes if the business recognises the importance of PCI to their organisation. We have some rare instance where clients do PCI just “because they want to, and they want to look good”, but more often than not, those attempts fizzle out once they realise it’s a rabbit hole you can’t get out of. A cost benefit analysis is key here, and a business case needs to be built, because you are going to end up spending a lot in this compliance, and that spend should be backed up with sound revenue and business in the pipeline – directly generated because of your compliance.

Having a Compliance Team

You need a go-to guy, or a go-to group for this compliance. We have experience where PCI is dumped into an organisation and every week we are dealing with different people. We have one customer who named a project manager to lead the project and his appearance in our meetings is as rare as Yeti sightings. We sit in the meeting and we go, “Where’s so-and-so?”. Some wide eyed junior IT guy goes, “Oh he’s busy with another project, and I am asked to lead”. Anything we discuss, he just goes, “OK, I need to check with so-and-so and get back to you.” Without decision makers in the team, we end up going around in circles and before you know it, 6 months have passed and we are still on the same agenda. It’s like going 3 levels deep in an Inception dream. Get a team. You don’t need to bring in 20 people in the meeting where 18 people sit away from the table, typing furiously at their laptops as if they are writing the next War and Peace novel. 3 or 4 key guys: Person in charge, network and server team representatives, developer rep and if you have SOC/security team rep. Everyone should either be an influencer or a decision maker, and we are good to go.

Business As Usual

We call it BAU. Many have suggested PCI is asking ridiculous requirements which are too difficult to meet. In reality, PCI is basically asking for baselines. The very least organisations should be doing to secure themselves. Security needs to be practiced, and not just implemented as a checklist over a short period of time. For instance, the requirement for daily log monitoring. This is not something you can conjure up when the auditor comes and audit. If you are not practicing it, you are not practicing it. Or simple things like CCTV monitoring. We faced a client doing recertification and on a pre-audit check, we found their CCTV had not be recording for 8 months due to maintenance. I asked why was this not reported or checked, and they sheepishly told me they had no clue and they had never bothered to even check since they passed their cert. PCI requires a fair bit from organisations, for example:

Daily Monitoring of logs, and access to secure area, weekly checks on FIM logs

Monthly checks on critical patches

Quarterly – Wireless Scans, ASV, Internal Scans

Half Yearly – Firewall review, user deactivation

Annual – Pentest, application testing, Risk assessment, training, Inventory checks and review, policy review, service provider review, Incident response, segment checks etc

Those are just part of the listing. So unless you plan to have sleepless nights during the audit period, it’s best to get these done as part of your day to day. We need to note that in most cases, these should be practiced in any case, regardless of PCI or not!

Yes, a lot of these are easier said than done. We are aware teams are being pulled sixteen different directions and PCI is just one of it. It falls back to how critical this compliance is. To many, it’s required to continue their business as it is a contractual obligation. So it’s not just about getting by, although in some cases that might work – but for PCI, we would recommend to embed these practices as much as possible into your organisation, so that when audit season comes, you don’t end up overeating your Ramen noodles.

Get in touch with us through pcidss@pkfmalaysia.com for any enquiry on PCI-DSS!

PCI-DSS IATA: Dissecting the New FAQs

July 13, 2017 / / 0 Comments

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

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

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

Firstly, the significant news.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

and now correctly states

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

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

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

Originally it stated

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

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

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

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

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

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

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

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

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

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

To give them credit, their explanation to this was:

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

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

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

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

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

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

So anyway, from this we learnt a few things

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

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

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

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

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

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

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

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

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!

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑