PKF AvantEdge

Tag: compliance (Page 3 of 5)

PCI-DSS Full Disk Encryption Part 1

May 25, 2019 / / 0 Comments

In PCI-DSS, one of the most difficult requirement to get through would be Requirement 3, that deals with stored credit card information and how to protect it. Aside from Requirement 10: Logging and Requirement 6: Software, Requirement 3: Storage makes up a bulk of the remediation effort and cost of PCI-DSS.

The excerpt ominously states at the beginning: Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.

It goes without saying that if you have credit card information on file for whatever reason, it would be a good time to relook at the necessity of it. If you don’t need it, get rid of it, because the cost of maintenance and remediation may not be worth whatever value you think you are obtaining from storage of card data.

If you do need it, well, PCI provides a few options for you to protect it: Encryption, Truncation, Masking and Hashing. In this series of articles we will be looking into encryption and more specifically Full Disk Encryption.

Encryption itself deserves a long drawn out discussion and the types of encryption – you have applications doing encryption through the application library, you have database encryption like TDE, you have file encryption or folder encryption, you have full disk encryption. One part is the encryption methodology. The other part of it is the encryption key management. The latter is the one that usually throws up a headache.

We will be exploring Full Disk Encryption or FDE, and where it can be implemented to comply to PCI-DSS.

There is a specific part in 3.4.1 stating:

If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.

So aside from the encryption being strong encryption and key management being done properly, PCI says, there are a few more things to be aware of for full disk encryption:

a) Logical access must be separate and independent of the native OS authentication

b) Decryption key must not be associated with the user account.

What does this mean?

Let’s look at Bitlocker for now, since that’s everyone’s favourite example.

Bitlocker has gone through a lot of stick probably because it’s a native Microsoft offering. Maybe. I don’t know. The fact is Bitlocker is able to use 128 or 256 bit AES so basically, in terms of strong cryptography, it’s possible. It’s the key management that’s the issue.

For key management, the recommended usage with Bitlocker is to use the Trusted Platform Module version 1.2 or later. The TPM is a hardware in your server that somewhat acts like a key vault or key management module, to simplify it. It offers system verification to ensure there is no tampering of the system at startup. Beginning with Windows 10, version 1803, you can check TPM status in Windows Defender Security Center > Device Security > Security processor details. In previous versions of Windows, open the TPM MMC console (tpm.msc) and look under the Status heading.

Bitlocker can also be used without TPM, although that means the system integrity checks are bypassed. It can operate along with Active Directory, although the newer versions of bitlocker doesn’t store the password hash in AD anymore by default. Instead a recovery password can be stored in the AD if required.

With the TPM, it’s still not the end of it, because we need to make sure that there is a separation of authentication for bitlocker to operate. In this case we will look to configure it with a PIN (which essentially is a password that you know).

First of all, let’s see what at the end we should be seeing.

So at the end you are basically seeing both file systems being encrypted. I’ve been asked before if all volumes need to be encrypted, and the answer is no, because bitlocker can’t do that anyway. Your system drive can’t be encrypted. So for PCI, it makes sense NOT to store card data in drives that are not encrypted.

The next thing we need to check is to ensure your set up has fulfilled the strong encryption requirement of PCI-DSS:

So you have a few things to ensure that strong crypto is enabled and key protectors are in place. So what you have is bitlocker now enabled. You also basically need to ensure you properly document the key management policy – include in AES256 or 128 that you are using, which drives are protected, key expiry date.

Keep in mind also the following:

FVEK (Full Volume Encryption Key) as DEK and VMK (Volume Master Key) as KEK.

FVEK stores in Boot sector (Volume meta data) in hard disk and VMK stores in TPM chip PCR register (it’s a Hardware chip which place in Motherboard).

In general, the above would fulfill PCI requirements. In our next article, we will write out on how logical access to the encrypted file system can be separated from the native OS authentication mechanism.

Meantime, please drop us any enquiries at pcidss@pkfmalaysia.com if you need to know more about PCI-DSS or any compliance matters in IT. We are here to help!

The Criticality of Project Management

May 2, 2019 / / 0 Comments

Project management over the years have gone through somewhat of a bad rap for technology projects, especially. They always seem like a luxury afforded by management, and whenever things go south in a tech project, the first stop for blame is always on the project manager. It’s a tough life. On one hand you need to appease the forces that hold the budget (the business) and on the other, you need to deal with a bunch of geeks who are talking binary stuff and whom you know would rather not have you in the room because you don’t talk tech as much as them.

We used to have a Project Management Office, receiving work from other large projects looking for business analysts, project leaders, program managers etc. It’s not cheap upkeeping these guys, what’s with their PRINCE and PMP certifications and their training and hours. The problem was also when the project ended, then basically we had to go look for other projects to take them on. It’s an expensive affair, unless you have a constant pipeline of internal or external projects to keep them busy. The thing was, we noticed project managers tend to stay as project managers. You couldn’t get them to go into tech audits, or develop software or do compliance work. At least, for the ones we hired.

In the past, Project Managers are fairly agnostic in terms of technical capability. They have a set of domains they are good at (whether they are good at telco projects, compliance projects, migration projects), but overall, the discipline more or less remains constant. Methodologies used by these managers include lean, SCRUM, Agile etc, or simply PMI/PMBOK guidelines, which some of our managers tend to gravitate to. But aside from this basic competency of managers, there is inherently a personality that project managers need to have. Leadership is obvious, decision making capability, the ability to stand strong when being questioned and able to communicate the project properly. The ability to pull people together, from technical to consultants to internal business, and yes, the inherent charisma that one must have to become a successful project manager. He or she needn’t be the most technical in the room, but they must be able to sniff bullshit and weed it out. Time, budget and quality are the basic triangles of forces that need to be met, and good project managers are aware of this.

Due to cost and lack of demand, we shuttered our PMO a few years back, but our guys still practice basic PM work in our compliance project, and in some smaller companies, we actually end up taking the informal role of the project leads. We wouldn’t call ourselves project managers, because not everyone who calls themselves project managers are actually project managers. However, for larger companies, we do defer to the project manager in charge, and in our time we have had some experience with some of the best in the business, and some of the absolute worst. The problem is because being a good PM or absolute garbage is so difficult to assess.

It MAKES A HUGE difference who you put as a project manager. It spells either success or complete doom to your project the moment you assign a good or a garbage project manager.

For a compliance like PCI-DSS, there are some specific traits a manager should have, as PCI is a fairly technical project. And most PCI projects tend to drag on past 4 months or so. Some even a year plus. It does require a fair bit of technical knowledge, persistence and goodwill to successfully manage the project. Here are some of what we observed, and having experience good ones, and the bottom of the barrel type of project managers, we can probably give a fair opinion of what are the points of success (between good manager (GM) and hapless manager (HM)):

a) Technical Capability

This is more of a trait than a skill.

The GM know they don’t need to be experts, but they also know they need to put their backs and time into understanding the whole thing and trying to absorb the technical matters of it. They would attend training sessions and they would ask very good questions. The hapless managers go: OK, everyone knows their spot here. Consultants, I will look to you to answer all PCI related questions. I am here to gather information for all parties, so I want everyone to come for every meeting we are going to have moving forward.

The hapless one basically just comes in, fires off a few questions on project matters, and then sidles down and constantly have a far away look in their eyes when we start talking about the project tasks and updates. Or glued to their phones or laptop, furiously typing out stuff with their brows knotted up. Their strategy is that everyone else will carry their own load so they don’t need to know anything technical because they are too busy with other more important things, like buying food for their cats online. Occasionally, they bark out some orders here and there but you can tell, they know jackshit. After 4 – 5 sessions, they are still clueless and that’s when they start losing grasp of reality, and if the consultants are not available, the whole project is stuck, and then they move into the stage of looking to blame people for their ineptitude. Oh yeah. We have had plenty of these experiences for sure.

b) Communication

This seems a given, and a good manager ensures everyone is on the ball and the scoreboard is known to all. They know how to manage downlines (the people that need to get things done), horizonlines (the peers who are managing other downlines) and uplines (the business or sponsors pressuring the project). This innate ability isn’t bestowed on the hapless one. The hapless manager’s basic modus operandi is to take whatever the team gives, and being questioned by uplines and peers, decide that they don’t know how to explain it and comes back to the team again to ask for more information on how to deal with the questions. There is a complete lack of awareness in these managers that they are unable to overcome. They are unable to argue their points succinctly and always give in when there is pressure. Because of their lack of skill and understanding, they have no clue what positions to take and often waste the entire project timeline by going back and forth hopelessly like grass (or lalang) swaying in the wind.

c) Responsibility

One of the true strengths of character is when things are not going right, the good ones take up the responsibility of the situation and face the issues head on. The hapless ones find a way out, and find a way to blame others. To them, it’s always someone else at fault and never them. This stems from their utter lack of confidence in the project, that the only way they can reverse the situation is by saying, “It’s not my fault.” They usually will turn to consultants, as they are external to the company, and seek to pin the blame on them. It’s tough, but it is what it is. Most companies, given the choice of an external party and an internal person, would side with their own regardless of facts.

d) Time Management

The LLB (Look Like Busy) Trait is a big problem with these hapless managers. Because of their lack of a), b) and c) above, they are running around like headless chickens, being pulled from one meeting to another, unable to resolve any issues properly. So their heads are constantly in their phones or laptops instead of properly leading the project. Firefighting, or looking to assign blame. You can also tell when they are not able to manage meeting times. Many times, we have received calls from project managers requesting either immediate meeting at their office, or to come onsite within the next day and they wail because we tell them we are either overseas or assigned to other audits and we can do a phone. Most don’t understand that (unless we are properly paid and engaged), we are not their outsourced compliance unit so they blame us for non commitment. We are their consultants and there is no service level that requires us to stay in the clients office all the time for their beck and call. Unless, again, if they pay us, but most don’t pay for consultants to sit down and wait for inept project managers to scramble around looking for ad-hoc meetings.

Because they are scrambling and blaming instead of working,these PMs now think they are utterly important because they are so busy, but the fact is because of the ineptitude, they are being forced to seek responsibility, communicate or have technical explanation of the project – all which they are unable to do. So it’s one excruciating, meaningless and useless meeting after another. It’s horrible to exist in that manner for a career, but we’ve seen this many times.

Once you solve a), b) and c), Time Management solves itself.

Bonus points: While this may not be always true, the way project managers approach meetings and projects can actually say a lot. If a PMP or PRINCE PM comes in, there is usually a methodology on the table, tools and actual project management software they utilise for reporting. They are able to standardise our reports to a point where it goes straight to the point and to what they know their uplines need to know. Some hapless PM comes in, not certified in anything, not having knowledge of any tools, software or methodology, but basically armed with an excel sheet they took from another project manager who took from another project manager who used it to make sandwiches. That’s how senseless we see some of these methods and tools sometimes an we just look at everyone across the table and everyone goes like: “What is going on?”

In conclusion, never underestimate the importance of Project Managers, especially in a long drawn project like PCI-DSS. While we have known some excellent ones in our time, we have also worked with yahoos out there that single-handedly managed to trainwreck projects. From this article, it may seem our experience is more on the latter, but the opposite is true – we have the privilege to have worked with some really excellent ones that have also helped us get better, over these years. They are absolutely precious resources in a project, trust me. It’s just that when we do face one or two hapless PMs, it stands out a little bit more because we are so used to working with good ones!

Yes, we have shuttered our PMO as an advisory a few years back, but we also recognise the need for great PMs that might be able to help us out in our projects. If there is any interest, drop us a note at avantedge@pkfmalaysia.com and we will get in touch wth you.

PCI and the art of scoping

May 5, 2018 / / 0 Comments

A lot of people we have met had told us this: “Since we are ISO27001, PCI should be a piece of cake, right?”

The context of this is because ISO27001 and PCI are often seen as distant cousins. They are both very relevant in our country and region (unlike other compliance like HIPAA), both deal with information security, and the overlaps between the Annex A controls of ISMS and PCI are evident. Therefore, the natural conclusion is ISO27001 is either a superset or a subset of PCI-DSS.

The problem with this assumption begins right at the start. In ISO, the scoping is largely determined by information that matters to your business. Before the iteration of 2013, scoping was generally done in a cowboy sort of manner. We met a company who had tons of sensitive information and told us they were ISO27001 compliant – and their scope was the security of their printing documents. Yes. How they literally secured the hard copies of the printouts. That was their scope statement.

Now 2013 version of ISO27001 had tried to stem these shenanigans by introducing interfaces and dependencies. Basically now the scope needs to cover information that are deemed important enough to protect from business perspective. This would cover the products and services relevant to the context of the organisation. Overall, scope determination of the ISMS can be a prolonged matter if you have a large organisation, and is often subjected to the business side of the organisation.

PCI scope?

It’s determined by the information that matters to the payment card brands, not your organisation. Credit Card Information. Primary Account Number. That’s it.

If you store, transmit and process PAN, PCI applies. If you don’t do any of these, and you do not influence any transactions in the payment card flow, then PCI doesn’t apply.

Often, people express utter shock that PCI doesn’t have any business continuity requirements. In terms of the holy trinity of information security – Confidentiality, Integrity and Availability (CIA), PCI primarily focuses on Confidentiality. Integrity is only focused in terms of its relation to confidentiality (Integrity of logs, integrity of system changes, system files etc), and there is no concern on Availability. Which makes sense. Between you closing down your business for one week versus you losing credit card information of your customers, the latter is viewed as more critical to the payment brands than the former. Although from a business perspective, a loss of business for a merchant is a loss of business for the entire data flow, upstream or downstream, so PCI not really caring about your RTO or RPO may be counter productive – but that’s an argument for another day.

At the end PCI scope boils down to you storing, transmitting or processing card holder data (CHD). Even if you don’t do any of these 3, you might still be in scope if you influence the security – an example would be those SAQ A e-commerce merchants that redirects requests to another PCI service provider. Even though they don’t deal with the CHD, they influence the transaction through their redirects, therefore, some parts of the requirements need to be met.

So – before we start our PCI journey, it is  very important to know what is the scope that is covered in your PCI environment. We may not want to take the whole environment as IN SCOPE – for cost, quality and timeline purposes. Our normal practice here is to reduce the scope as much as we can, a process we consultants term as “Scope Optimisation” simply because it sounds grand. I mean it sounds better than “Reduce your scope” which generally is interpreted to “reduce your price”.

In general, there are six things that we have to compile before we truly initiate the PCI journey.

a) Location and Address of the PCI scope. This is simple enough. Usually your data center is in scope. Depending on whether you store, transmit or process card data in your other offices, those come in scope as well. A question here would be – what about HQ, where our administrators access the PCI systems in DC, via a VPN connection? Ah. The secret sauce of putting things out of scope in a remote location where there is no storage, transmission or processing (lets just shorten these to STP from here on) of card data but there is access from an admin systems – multi-factor authentication. As long as this is in place, while the admin system is in scope, the location itself is then put out of scope. So you can connect from Starbucks, your home, or Timbuktu, and you would not have these locations dragged into your precious scope.

b) Applications that STP CHD. Store, transmit or process card holder data. Many queries have been like – oh, do we need to use PA-DSS applications? Well, if you do use PA-DSS certified applications, it would be very useful. However, even if you do not, you can still access that application as part of your scope under Requirement 6. In fact, some applications may not even be able to be PA-DSS for many reasons, such as it not being part of the authorisation or settlement flow but still storing card data. A custom CRM for example would be one that cannot be PA-DSS but still in scope for card data application. OTC (off the counter) products that store card data are still in scope, however, they need to be assessed properly to determine if there are any security issues that may influence the confidentiality of card information.

c) Network Diagram – an updated network diagram is a must. And a network diagram needs to be detailed enough to be able to differentiate the PCI and non-PCI zones. The important thing we need to take note on the network diagram is the proper demarcation of PCI zones, so we know what are:

  1. Card data environment in scope (CDE-IN-SCOPE) – ZONE A
    1. Any system that store or process or transmit CHD
    2. For example, application server, Database server
  2. Non-Card data environment in scope (NON-CDE-INSCOPE) – ZONE B
    1. Any system that require to communicate with CHD
    2. For example, patch server, anti-virus server
  3. Out of Scope – ZONE C
    1. System not related and has no communication with CHD – but might communicate with NON CDE IN SCOPE.
    2. For example, CCTV server in your office environment

d) Asset List for PCI – the asset list is critical because this relates directly to the effort and remediation costs of your PCI program. There is a huge difference in doing pentest for 200 systems versus 20 systems. So in this case, we don’t care about your assets considered not in scope, we want to know the assets in CDE and in NON-CDE in scope (Zone A and B).

e) Public IP addresses – this is needed because of ASV scans required. ASV scans are security scans done by the ASV (Approved Scan Vendors) of PCI. You can’t do it yourself, you need to get an ASV to do this for you.

f) Data Flow Diagram – This shows the card data flow in your organisation. Basically every channel where credit card enters into your environment, stored and process and exits. This details the lifecycle of CHD in your organisation whether it ends up being stored in a database for seven years, or passed out to another service provider. It’s essential to understand this – and if you have multiple channels where card is being entered (e.g e-commerce, POS, MOTO, Call Centers, KIOSKS etc) you need to document each of these from start to end.

So there you have it. PCI scoping at your fingertips. Drop us an email at pcidss@pkfmalaysia.com and we can have a free session with your organisation on what could be your possible scope, which likely may not be just your printouts coming out of your printer!

PCI-DSS and the Pervasive Certification Myth

March 4, 2018 / / 0 Comments

The pervasive certification myth is so pervasive in PCI-DSS that we are going to give it its own Acronym: PCM. Because we are so tired of having to explain this over and over, we are going to canonize this corporate disease called PCM and forever immortalise it as the one of the most deluded, misleading and misinformed quackery to ever blanket the PCI-DSS industry, the same sort of quackery that insists urine therapy should still be used today for natural teeth whitening. Yes, it seems appropriate to compare these two in the same breath.

Please note that the below article is satirical (borne out by our immense frustration and oftentimes resignation that this will never be properly sorted out, ever).

PCI-DSS and PCM

The history of PCM has its roots in PCI-DSS itself being considered as a standard that can be certified against. Because of the name, Payment Card Industry Data Security Standard, immediately, fairly important people in the financial and banking industry who generally prefer to spend more time golfing and drinking fine wine than to actually read the standard and understand it better – these people concluded that like any other standard, there must be a certificate to ‘prove’ you are compliant. I mean, why not? ISO9001 has it. ISO27001 has it. Additionally, these were the same people who insist on having a certificate for literally everything that they do in their corporate life, from attending a half hour seminar talk on how to grow daffodils, to sleeping though a computer based training webinar; to providing a poor soul whose car has broken down some assistance in pushing it to the side of the road. Where’s my certificate to prove that I helped you, my good man?

Apparently, certificates are absolutely critical to our financial industry, without which our entire economy would surely descend into the Dark Ages of Financial Purgatory. In the same way, it has perpetuated into PCI-DSS that despite everything that the PCI council has said and has begged the entire industry to reject this PCM quackery, 99% of the time, we are still faced with the mind boggling, soul numbing, heart wrenching email or question stating: I want to see your PCI certificate.

Here’s the official statement from PCI council:

FAQ #1220

Are compliance certificates recognized for PCI DSS validation?

 

No. The only documentation recognized for PCI DSS validation are the official documents from the PCI SSC website. Any other form of certificate or documentation issued for the purposes of illustrating compliance to PCI DSS or any other PCI standard are not authorized or validated, and their use is not acceptable for evidencing compliance. The use of certificates or other non-authorized documentation to validate PCI DSS Requirement 12.8 and/or Requirement 12.9 is also not acceptable.

 

The PCI SSC website is the only source of official reporting templates and forms that are approved and accepted by all payment brands. These include Report on Compliance (ROC) templates, Attestations of Compliance (AOC), Self-Assessment Questionnaires (SAQ), and Attestations of Scan Compliance for ASV scans. Only these official documents and forms are acceptable for the purposes of compliance validation.

 

Because certificates and other non-authorized documentation are not officially recognized, entities that receive these documents to indicate their own compliance (for example, from a QSA or ASV) or another entity’s compliance (for example, from a service provider) should request that official PCI SSC documentation be provided. Any organization issuing, providing, or using certificates as an indication of compliance must also be able to provide the official documents.

OK.

We actually would prefer the answer to just be: “No. For heavens’ sakes stop asking the council such questions and waste our typing time on the keyboard!” But we are not the council. Else we will be out of work within a day.

You ask then: Wait a minute, if there is no certification, what are we supposed to submit then?

Well the answer to that is: it depends.

If you are a level 1 merchant or service provider, then you submit your Attestation of Compliance (AoC) signed off by yourself and the Qualified Security Assessor (QSA) or Internal Security Assessor (ISA). You may also submit your ASV scan reports, or if requested your full Report of Compliance (RoC). But rarely those last two are needed. What is needed is the AoC. That’s your PCI ticket. If you are doing a self signed Self Assessment Questionnaire (SAQ), you submit in your AoC, and if required the full SAQ documents with your response on the applicable questions.

I suppose we (the consultants, advisors, auditors) didn’t help in stopping this PCM disease ourselves, by oftentimes referring to Level 1 as a PCI ‘certification’. It’s more of figure of speech than anything, meaning that a third party is to validate your compliance as opposed to you doing a self validating process under the Self Assessment Questionnaire (SAQ) path. So we end up saying certificate, certificate, certificate and finally everyone asks, well, then, where is my certificate? As in the actual, real certificate, and not this figure of speech one?

It also doesn’t help that most (if not all) QSAs play along with this ridiculous fallacy. They will come up with their own ‘certificate’, made to look very official, very grand, very formal and very important looking. You know, those papers with flowery borders at the side and some huge bold statement saying, So and So are official certified, and signed off by a very important person. Some even put a seal in there for good measure. As if they graduated from Hogwarts.

The truth is, that certificate paper is just piece of paper. It’s not acceptable in any way for PCI-DSS and shouldn’t even be requested by acquirers or banks. Yes, no matter that the QSAs even make it look like it’s gold laced, and our customers print it out in all its Arial font glory, and spend a few bucks to frame it up nicely. That’s all well and good, and they are entitled to do anything with it, but PCM rears its ugly head when acquirers, banks, customers and clients insist on having it. INSIST.

If you have gone through the level 1 validation with a QSA and that QSA is able to provide one of these certificates, as a consequence of the PCM disease, then I suppose it’s fine, you can just play along as opposed to haranguing them about the PCM disease like what we are doing right now. Just provide them that dratted document. This does increase the myth further though, and it starts infecting the entire industry even more, because, now the acquirer/client/bank will go to another company and declare they need the certificate that the other merchant had provided. Until they reach a small company who is doing their own SAQ, whereby they say: “Yes, even if you are doing a level 4 merchant compliance, you should still be having a certificate! Come on now, chop chop!”

And that’s what we are facing.

Without exposing which industry right now we are assisting (those following our recent blog posts may venture a very educated guess), we are helping a lot of merchants undergo level 4 self signed SAQs. This is absolutely allowed by PCI-DSS. There is zero requirement to get QSAs involved. ZERO. In fact, PCI council printed this out in their Top 10 myths of PCI-DSS.

So now, our clients want to submit their compliance document (AoC) to the group requesting for it and here is the summary of response they received: 

a) The group requesting our client’s compliance says that the SAQ needs to be sent over to the QSA so that the correct SAQ type applicable to our client’s business will be determined. (WHAT?!)

b) Our client only now has to submit the PCI DSS compliance certificate.

I looked at it and we just shrugged. Resignation. PCM. This is what this disease has caused.

Firstly – the first phrase is proof that the writer has not bothered to even understand the background of SAQ and PCI.

No. The SAQ DOES NOT NEED TO BE SENT TO THE ASSESOR! It doesn’t even make sense. You are telling me to send the assessor the SAQ document I filled up so they can determine what SAQ I need to fill up? What sort of recursive devilry is this? Is this one of those tricky while-do loop we do as programmers that never ends because the condition to end is the condition to begin as well?

How many times have the PCI council stated that it is not the QSA’s role to define the validation requirements of the merchant, or the service provider or the bank. It’s NOT. The QSA’s role is to assess based on whatever validation requirements that has been determined. Yes, they can advice. Yes, they can with their amazing experience and god-like understanding of PCI-DSS, suggest which validation requirement to take. But at the end, the acceptable validation requirements are based on the bank, the acquirer, or worst case whichever company requesting the merchant to be compliant. If none, then the validation requirements must fall back to the guidelines provided by PCI SSC, which means, it falls back to the individual card brands. We are not going to go into that for now, but in general, VISA/Mastercard has an agreement on merchant levels, but Amex has some weird levels of their own. What we are stating is that, if a merchant is considered a level 4 merchant based on its volume, but the acquirer decides that they must still undergo Level 1 validation, then that’s the acquirer’s call. But it’s never the QSA/consultant to decide this. The QSAs job is to assess the company against the validation requirements and have an opinion if it is pass or fail. The type of validation is determined by the acquiring party. So, no the first sentence is already incorrect, never mind the recursive gibberish.

The second sentence is where PCM disease kicks in. Because nothing is known about the ‘AoC’, everyone immediately assumes that the certificate is an official document from PCI-DSS and it should be sent in. No. If the merchant is doing a level 4 self signed SAQ, that is 100% allowed by the council and by their acquirers, where in Thor’s Holy Hammer are they going to get a certificate to fulfill your insatiable lust for PCI certificates??!!

I am tempted to just have my 5 year old son draw a smiley face on an A4 paper, and stick one of his favourite Cars 3 character sticker on it, sign off and laminate it.

Go ahead – I dare you to google “PCI certificate” and click on ‘images’ and see the result of PCM in our world. Thousands upon thousands of PCI certificate documents, some even daring to put the PCI SSC logo on the certificate as if to say PCI SSC has endorsed the certificates, to provide these documents an air of official integrity. Even worse, we see QSAs giving ‘certificates’ for clients undergoing SAQs. Wait, if they have audited them, then OK, fine. But if is a self signed SAQ, how can certificates be even provided?

We are not saying what they are doing is wrong. No, it’s not wrong to provide a PCI certificate. But PCI SSC has clearly stated that if you guys want to do this, you must state clearly that these are not official PCI documents and these are supplementary, not mandatory and only provided by the QSA/ASV and not endorsed by PCI-SSC and cannot replace the official documents like AoC or RoC. Basically, PCI is just saying, “Put it up in your office or your lobby so you can brag, but please don’t show it to us and say you are PCI compliant, we rather be looking at a piece of art written by a 5 year old kid with some Cars 3 character sticker on it.”

Finally, to end this article (or rant, it may seem to some). The reason why this is written is to drive home the fact that PCI-DSS has no actual paper certificates. None. Whatsoever. The actual document you should be requesting for is the Attestation of Compliance (AoC). Please do not ever request for the Certificate of Compliance ever again because this means, you are guilty of spreading the epidemic of PCM across the world.

Note: This article is meant to be satirical, for us to blow off steam and not intended to offend any party or to dispense actual advice. There is actually no such thing as an official PCI Pervasive Certification Myth. At least, it has not yet been officially defined, as far as we know.

 

 

 

IATA PCI-DSS: New FAQs!

January 23, 2018 / / 0 Comments

So, it has been a while since we’ve updated on the ongoing PCI-DSS program from IATA. Just a brief recap then: Airlines have demanded that IATA support their own internal compliance project by making the BSP (Billing Settlement Plan) card sales channel PCI DSS compliant. This is why IATA Accredited Travel Agents now need to become PCI DSS compliant by 1st March 2018. Yes, that’s roughly 6 weeks ahead of this writing. And no, it doesn’t seem like there might be any extension towards this compliance from IATA. However, there are some pretty big news headed your way on this compliance, as we are in touch with IATA over the last couple of months and also assisting many travel agencies to get PCI-DSS sorted out in their payment channels.

However, for this article, we will focus on the brand new FAQs that just came out a few days ago (18 Jan 2018)! You can find the updated FAQs here at http://www.iata.org/services/finance/Documents/pci-dss-faqs.pdf, and we are going to look through a few changes.

FAQ #3

What if I do not have an acquirer?

Old FAQ: We suggest that you contact the credit card branch that you are working with.

New FAQ: In that case, you are solely accountable for the PCI DSS compliance of the BSP card transactions you are making on account of the airline whose ticket you are selling. We suggest you contact your GDS provider who can provide some guidance, and then review through which of your systems card details transit or are stored. Starting from this you will know which of your systems
must undergo a PCI DSS evaluation.

Our opinion: The first FAQ was of course, not exactly extremely helpful, since most credit card branch does not give two hoots about travel agencies banging down their doors in search of their response. The new FAQ is basically saying, well – you just need to figure out yourself then, but you can ask the GDS guys if you wish. We have. The GDS guys are very important in this factor, because they first need to be PCI compliant. Sabre, Amadeus and I think Galileo Travelport is. Secondly, they can give some guidance on how agencies can approach PCI based on the client software that is installed on the agency side.

What do we mean by this? Because for agencies not storing credit card, they can possibly be eligible for shorter SAQ (Self Assessment Questionnaires) for PCI. An SAQ D has 340+ questions. An SAQ A has only 20+. If an agency uses the GDS for credit card passthrough transactions (i.e the credit card form of payment), and not store credit card information in the back office or any electronic form (email, skype, excel etc), they might qualify for shorter SAQs. The question is which?

Some advisors claim the SAQ C is correct due to the fact that the GDS is a payment system. The reasoning is that this is no different from integrated POS systems like Micros. In Malaysia, we have hundreds of different vendors in POS solutions for retailers, F&B franchisees etc. But is the GDS really like an integrated POS solution? SAQ C has around 160 questions. The amount of time you will spend on this is probably the same amount of time taken to watch two seasons of the Game of Thrones. Or three, depending on whether you binge watch or not.

Some advisors veer to the other extreme, claiming that the GDS client is simply a browser system that is redirecting the entire card data processing work to the GDS provider, so they are eligible for A. 22 questions. Maybe an episode of Seinfeld. But A is generally for a web browser based site with absolutely zero handling of credit card on their end, not just systematic, but also manual. The only way this works for travel agency is that they outsource an entire call center to handle their MOTO business and do not accept walk-in customers. I don’t think that’s happening. Most feedback I get from livid agencies about PCI-DSS is that they are struggling too much on thin margins. So, no, SAQ A is entirely too liberal.

SAQ C-VT has a seemingly better balance to it, as discussed in our previous articles Part 1 and Part 2.

We even sent out queries to two GDS (their names pending once I get their agreement to publish) and their responses were these

Amadeus: (When Queried if SAQ C-VT is correct to be filled, and if the Amadeus Selling Platform can be eligible for VT): Basically, if the payment is done via Amadeus and entered manually from a personal computer directly into the GDS – you have a right form for Amadeus agents and tick it off with confidence. 

I believe your original question was ‘If Amadeus is considered virtual payment terminal?’

Our answer is Yes.

Sabre: (When asked if their client acts as a VT, defined by PCI as having “Internet-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions.”) Yes, Sabre Red Workspace client requires an internet connection to authenticate and then it requires connections (dedicated or ISP with VPN) to connect to Sabre and no, it does not do batch processing. You may consider SRW is a virtual terminal and guiding your travel agency clients to achieve their goal.

Travelport (Galileo):  (When asked if their client acts as a VT, defined by PCI as having “Internet-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions.”)

Yes. Galileo client does not store credit card information on the client software and client software requires internet connectivity, and cannot do batch transactions.

Based on these ‘guidance’ from GDS which IATA seem to defer to, SAQ C-VT is a likely possibility, as long as all the other eligibility are met. The GDS all claims they are virtual terminals, but that itself (while an important eligibility) isn’t the ONLY eligibility for SAQ C-VT, so you need to ensure the others are met before claiming SAQ C-VT is correct or your business.

Whew. That was a long one. Now back to our FAQs.

FAQ #9 : As a travel professional issuing and selling airline tickets, am I considered a merchant?

This is removed and rightly so. Though the previous response was right: “All the airline transactions processed through a GDS (Global Distribution System) and IATA BSP, the airline itself is considered as the merchant, not the travel agent.”

It only serves to confuse an already confused population further. It’s better they don’t explain this, because some agencies interpret this as IATA saying they are not ‘merchants’ so they need to be ‘service providers’. WHAT! So, yeah, we can explain in another article but this is better left out.

FAQ #22: We already have a PCI DSS Compliant certificate issued by a third party.
Is this enough to cover our BSP or do we need to complete more forms?

Not an addition or whatever, but I still wish that they would change this because the answer doesn’t match the question. The answer is lifted directly out of the PCI-DSS Top 10 Myths addressing the need for a QSA to be involved in the process. The answer is , it is recommended, but NO, for Level 3 and 4 merchants, there is no requirement to get a QSA involved.

Finally, a bonus opinion here.

Many agencies are still faltering in their PCI-DSS compliance. Some equate that just because they are level 3 and 4, they do not need to do ASV scans or penetration testing. Likewise, there are those who *might* theoretically (we don’t know any) qualify for level 1 or level 2 based on their volume, automatically assume they need to do ASV scans and do pentest for everything in scope.

NO.

Your merchant level DOES NOT dictate whether you need to conduct PCI scans or not. We need this to be clear. Because the table published in the FAQ from IATA for FAQ#13 isn’t clear (not their fault, this was lifted from the Mastercard site) – the column “Validated By” states ‘merchant’ and below “Approved Scanning vendor” for level 2 and below. This immediately presupposes that an ASV must be involved. This is incorrect.

Your level (determined by your card transaction volume) determines your VALIDATION TYPE. Validation type there are 3: QSA Certified/Validated; Validated SAQ by QSA/ISA and SELF SIGNED SAQ by MERCHANT OFFICER. That’s it. Your level doesn’t determine how you go through PCI, it determines how it is validated. And it’s not set in stone. Your acquirer can bypass these guidelines and decide that even if you only do ONE transaction a year, you still must go through level 1 compliance (audited by QSA). This is actually quite common!

So what actually determines what on earth you actually do in PCI-DSS?

Well, it’s your business. Or, for Level 2 merchants and below, your type of SAQ. You see, it’s your business that determines your SAQ type, it’s your SAQ that determines what you need to do, and based on what you have done, it will be validated in either of the 3 ways we’ve described above. That’s the harmony of PCI. That’s the zen. The yin and yang. The balance in the Force.

So, for instance, if you are doing SAQ A, SAQ B or SAQ C-VT, please point out to us the fact that you are REQUIRED to do ASV scans on all your internet address (some are told, even their dynamically allocated broadband IP must be scanned by ASV).

None. Magically, SAQ A, SAQ B and SAQ C-VT DOES NOT HAVE ANY requirement for ASV or penetration testing. For us who can provide these services, of course it kind of sucks since now those going through these SAQs don’t need our services anymore. But we rather tell them straight the correct way and sacrifice that part of our business than to let them know wrongly and give consultants a bad name. So what SAQ you are doing will determine whether you need to get something scanned or not.

Now, of course, do not be tempted to fit your business into the easiest SAQ for the sake of it (see the example of travel agencies with GDS doing SAQ A) – there are huge eligibility requirements for these 3 SAQs and not many agencies can meet it. If you practice accepting cards through email, or photos on Whatsapp for your credit card; or store in back office for later processing, or have Enhanced Data Services from Visa/Mastercard or a thousand other ways you can be receiving credit card, you likely need to fit back into the dreaded SAQ D. But what we are saying is that if you ARE eligible for A, B or C-VT, then those will determine whether you need to do any testing or not.

It is our opinion that testing and scans should be done regardless for security sake, not so much for compliance but the choice is yours. You need to make that decision for your own business. Because that’s what heroes do.

If you have further queries on PCI-DSS or just how we are currently helping our clients get through PCI, drop us an email at avantedge@pkfmalaysia.com. We will respond ASAP!

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑